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Digital Library Federation / Aquifer Implementation 
Guidelines for Shareable MODS Records 

Introduction 

The primary goal of the Digital Library Federation's Aquifer Initiative is to enable 
distributed content to be used effectively by libraries and scholars for teaching, learning, 
and research. The provision of rich, shareable metadata for this distributed content is an 
important step towards this goal. 

To this end, the Metadata Working Group of the DLF Aquifer Initiative has developed a 
set of implementation guidelines of the Metadata Object Description Schema (MODS) 
specifically for use in describing digital cultural heritage and humanities-based scholarly 
resources that are to be shared within the Aquifer Initiative and beyond. 

The authors of the implementation guidelines are aware that the requirements and 
recommendations set forth here are not currently met by most current and potential 
Aquifer participants. However, we developed these as a set of guidelines for creating 
rich, shareable metadata that is coherent and consistent, and, thus, useful to aggregators 
and end users. We do not intend these guidelines to dictate local metadata practices, but 
we do hope that these guidelines will help Aquifer participants share metadata among 
themselves and with other institutions. 

The joint DLF and NSDL Best Practices for Shareable Metadata document provides 
overall guidance on interoperability of metadata. We recommend that metadata authors 
be familiar with these best practices in addition to the implementation guidelines 
presented here. 

Other guiding principles and conditions t hat have informed the DLF MODS 
Implementation Guidelines are: 

■ They are currently based on the MODS Schema version 3.2. 

■ The resources to be described are digital (either born digital or digitized from 
analog originals) cultural heritage and humanities-based materials in keeping with 
the Aquifer collection focus on American life and culture. 

■ Keeping in mind the needs of end users and aggregators, these guidelines seek to 
provide as simple a structure as possible for presenting metadata. They 
recommend that metadata about content and digital and analog carriers all appear 
in the main record. The guidelines try to make clear how an aggregator might use 
the metadata in services for end users and make recommendations for the 
inclusion or exclusion of information based on that use. 

■ The guidelines are specifically meant for metadata that will be shared with others 
(whether through the Open Archives Initiative Protocol for Metadata Harvesting 



1 http ://www. loc . go v/standards/mods/ 

2 http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7PublicTOC 
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(OAI-PMH) or some other means), and, as such, is focused on how to derive 
metadata that will make sense and be useful outside of its local context. 

■ Because the first phase of the Aquifer Initiative is focused on using the OAI PMH 
to aggregate metadata, suggested mappings from MODS to simple Dublin Core 
have been provided. However, this is only to assist participants in meeting the 
simple Dublin Core requirement of the OAI protocol, and is not a 
recommendation to provide simple Dublin Core as the primary metadata format. 

Included in these guidelines are a general overview of requirements and 
recommendations, advice concerning the attributes common to all MODS elements, 
discussions of each element in the MODS 3.2 Schema, and eight full examples of MODS 
records that meet these guidelines. Each element discussion includes: 

■ A list of the element's attributes and subelements, where applicable; 

■ A summary of the guidelines requirements; 

■ The element definition from the MODS User Guidelines ; 

■ A discussion of use, including requirements and recommendations, for the 
element, subelements, and attributes (except those that are common to all MODS 
elements); 

■ A discussion of how elements may be used by aggregators; 

■ Example(s) of the elements that illustrate, at minimum, usage required by the 
guidelines; 

■ Suggested mappings to simple Dublin Core 4 ; and 

■ Reference to further discussion, if any, in the DLF/NSDL Best Practices for 
Shareable Metadata document. 

These guidelines follow the language of RFC21 19 5 in expressing requirements and 
recommendations for MODS encoding practices. These are as follows: 

■ "REQUIRED" designates an item that is an absolute requirement of the 
guidelines. 

■ "REQUIRED IF APPLICABLE" designates an item that is an absolute 
requirement of the guidelines if it is applicable to the resource being described. 

■ "RECOMMENDED" designates an item that an implementer may ignore, but 
only if she has fully weighed the implications of doing so. 

■ "RECOMMENDED IF APPLICABLE" designates an item that is applicable to 
the resource being described and an implementer may ignore, but only if he has 
fully weighed the implications of doing so. 

■ "OPTIONAL" designates an item that an implementer may use at his own 
discretion. 

■ "NOT RECOMMENDED" designates an item that an implementer may use, but 
only after she has fully weighed the implications of doing so. This item is 
discouraged. 



3 See http://www.loc.gov/standards/mods/v3/mods-userguide.html . 

4 The starting point for Dublin Core mappings is the Library of Congress' MODS to Dublin Core Metadata 
Element Set Mapping Version 3.0 (June 7, 2005) available at http://www.loc.gov/standards/mods/mods- 
dcsimple.html/ . 

5 See http : //www . f aqs . org/rfc s/rf c2 1 1 9 . html . 
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Note that a requirement or recommendation for a subelement or attribute should be taken 
within the context of its parent element. For example, <roleTerm> is required only if its 
parent element <role> (itself a subelement of <name>) is used. 

The current and former members of the Aquifer Metadata Working Group are: 

■ Sarah L. Shreeves (University of Illinois at Urbana-Champaign): 2005-2009; 
Chair, 2005-2007 

■ Jenn Riley (Indiana University): 2005-2009; Chair, 2007-2009 

■ Laura Akerman (Emory University): 2006-2009 

■ John Chapman (University of Minnesota): 2005-2008 

■ Melanie Feltner-Reichert (University of Tennessee): 2006-2008 

■ Kat Hagedorn (University of Michigan): 2007-2009; ASHO Core Team Liaison, 
2006 

■ Bill Landis (California Digital Library/Yale University): 2005-2006, 2007-2009 

■ Tracy Meehleib (Library of Congress): 2006-2009 

■ Elizabeth Milewicz (Emory University): 2005-2006 

■ David Reynolds (Johns Hopkins University): 2005-2009 

■ Gary Shawver (New York University): 2005-2008 

The Aquifer Metadata Working Group would like to thank the many individuals and 
groups who commented on the January 2006 draft of the Implementation Guidelines. 
These guidelines are much improved because of the many comments and questions we 
received. 
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Summary of Requirements and Recommendations 



Be merit 


clement 

Requirement 

Level 


Subelement(s)/ Attributes 
requited if element used 


auDeiement^si/ mujiduiks 
recommended or 
recommended if applicable 


Repeat 
-able 


Content 
Controlled 


<titleInfo> 
(page 14) 


Required 


- <title> 


- type attribute 

- authority attribute 

- <subTitle> 

- <partName> 

- <partNumber> 

- <nonSort> 


Yes 


Recommended 
authority 

attribute limits 
content 


<name> 
(page 18) 


Required if 
applicable 


- <namePart> 


- type attribute 

- authority attribute 

- <role><roleTerm> 


Yes 


Recommended 
authority 

attribute limits 
content 


<typeOfResource> 
(page 24) 


Required 


None 


-collection attribute 

-manuscript attribute 


Yes 


Yes 


<genre> 
(page 28) 


Recommended 


- authority attribute 


N/A 


Yes 


Recommended 
authority 

attribute limits 
content 


<or±g±nInfo> 
(page 30) 


Required 


- <placeTerm> a nd 

type attribute when <piace> 
used 

- authority attribute when 
<placeTerm type=" code" > 
used 

- At least one date 
subelement 

- At least one date 
subelement must have 
attribute keyDate="yes" 


- <publisher> 

- encoding attribute for date 
-point attribute for date 
-qualifier attribute for date 

- <edition> 


Yes 


Recommended 
authority and 
encoding 

attribute limits 
content 
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Element 


Be me tit 

Requirement 

Level 


Subelementts)/ Attributes 
required if element used 


Subelemerrtfs)/ Attributes 
recommended or 
recommended if applicable 


Repeat 
-able 


Content 
Controlled 


<language> 
(page 36 


Required, if 
language is 
primary to 
resource 


- <languageTerm> 

- each type attribute 

- authority attribute when 
type="code" 


N/A 


Yes 


Required 
authority 

attribute limits 
content 


<physical 
Description> 
(page 40) 


Required 


- <digitalOrigin> 

- <internetMediaType> 


- <form> and authority 
attribute 

- <extent> 

- <note> 


No 


Yes (see 
guidelines) 


<abstract> 
(page 44) 


Recommended 


N/A 


N/A 


Yes 


No 


<t abl eOfCon tents> 
(page 46) 


Recommended 
if applicable 


none 


- xiink attribute 


Yes 


No 


<targetAud±ence> 
(page 48) 


Recommended 
if applicable 


none 


- authority attribute 


Yes 


Recommended 
authority 

attribute limits 
content 


<note> 
(page 50) 


Recommended 
if applicable 


none 


none 


Yes 


No 


<subject> 
(page 54) 


Required if 
applicable 


At least one subelement is 
reauired as <subiect> is a 
wrapperelement. 


- authority attribute 

- <topic> 

- <geographic> 

- <temporal> with encoding, 

point attributes 

- <f-7f- 7pTnfo> 
^ (_- ^ (_- ^ c M iiX yj*^ 

- <name> 

- <hierarchicalGeographic> 

- <geographicCode> with 
authority attribute 


Yes 


Recommended 
authority 

attribute limits 
content 
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FIp mo nt - 

□CI 1 ICI IL 


Requirement 
Level 


Subele mentis)/ Attributes 
required if element used 


Subele mentis)/ Attributes 

ICW wl 1 II 1 ICI IUCU / 

recommended if applicable 


Repeat 
-able 


Content 
Controlled 


<classif±cat±on> 
(page 64) 


Optional 


- authority attribute 


- edition attribute 


Yes 


Rpn i linprl 
authority 

attribute limits 
content 


<rel at edit em> 
(page 66) 


Recommended 
if applicable 


- type attribute 


- xiink attribute 


Yes 


In some cases 
(see guidelines) 


<i den tifi er> 
(page 72) 


Recommended 


- type attribute 


- invalid attribute 


Yes 


Required type 
attribute limits 
content 


<locat±on> 
(page 76) 


Rein i linprl 


- <url> 

- one and only one instance 

\J 1 ^ -L C/Cd L. _L \Uil-' 

C 0 nta ins usage= "primary 
display" 


- authority attribute with 

<physicalLocati on> 
a ihp |p mp nt 

- access attribute with <url> 
subelement 




Recommended 
authority 

attribute limits 
content 


<accessCondition> 
(page 82) 


Required 


- At least one attribute 
type="use and 
reproduction " 


None 


Yes 


No 


<part> 
(page 86) 


Recommended 
if applicable 
(see guidelines) 


none 


- <detail> with type attribute 

- <extent> with unit attribute 
- <start>, <end>, <total>, 
<iist> subelements 

- <date> with encoding, 
point, qualifier attributes 

- <text> 


Yes 


No 


<extension> 
(page 92 ) 


Optional 


N/A 


N/A 


N/A 


N/A 


<recordInfo> 
(page 94) 


Required 


- <languageOfCataloging> 

- <languageTerm> 

- authority attribute 


- <recordContentSource> with 
authority attribute 

- <recordOrigin> 


No 


Required 
authority 

attribute limits 
content in some 
subelements 
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<titlelnfo> 



MODS Element 



Attributes 



Subelements 



<titleInfo> 



type 

authority 
di spl ayLabel 



<title> 

<subTitle> 

<partNumber> 



<partName> 
<nonSort> 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require the 
use in all records of at least one <titleinfo> element with one <title> subelement. 
Other subelements of <titleinfo> are recommended when they apply. This element is 
repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

A word, phrase, character, or group of characters, normally appearing in a resource, that 
names it or the work contained in it. 

DISCUSSION OF USE 

Titles are an extremely important access point for digital library resources, and are 
frequently used in brief record displays to assist end users in deciding whether to 
investigate a resource further. As such, at least one <titleinfo><title> element is 
required by these guidelines. Additional <titleinfo> elements should be used to 
indicate other titles for the resource. Do not include punctuation intended to delineate 
parts of titles separated into subelements of <titleinfo>. 

Choice and format of titles should be governed by a content standard such as the Anglo- 
American Cataloging Rules, 2nd edition (AACR2), Cataloguing Cultural Objects (CCO), 
or Describing Archives: A Content Standard (DACS). Details such as capitalization, 
choosing among the forms of titles presented on an item, and use of abbreviations should 
be determined based on the rules in a content standard. One standard should be chosen 
and used consistently for all records in an OAI set. 

When no title appears on the item being described, a title should be supplied. The 
guidelines recommend against the use of brackets or other punctuation to indicate the title 
has been supplied rather than appearing on the item; the displayLabel attribute, however, 
may be used to indicate that the title is supplied. In supplying a title, consider 
expectations of end users for naming of resources. Follow the rules of the chosen content 
standard for the construction of the supplied title. 

Repeat this element as necessary. 
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Attributes: 

All attributes are applied to the <titleinfo> element; none are used on any subelements. 
type [RECOMMENDED IF APPLICABLE] 

For the primary title of the resource, do not use the type attribute. For all additional 
titles, the guidelines recommend using this attribute to indicate the type of the title being 
recorded. Allowed values are: 

abbreviated 
translated 
alternative 
uniform 

authority [RECOMMENDED IF APPLICABLE] 

The authority attribute is used to indicate that the title given is controlled by a record in 
an authority file. The guidelines recommend the use of authoritative titles and the 
authority attribute whenever the type attribute is set to "uniform" and/or 
"abbreviated" . Values for "uniform" should be taken from the Source Codes for 
Name and Tide Authority Files 6 maintained by the Library of Congress. Values for 
"abbreviated" should be taken from the code list for MARC field 210 in the MARC Code 
Lists for Relators, Sources, Description Conventions , also maintained by the Library of 
Congress. The authority attribute should not be used with titles having a type attribute of 
"translated" or "alternative" since these title types would not be represented in an 
authority file. 

displayLabel [OPTIONAL] 

The displayLabel attribute may be used whenever appropriate to indicate the preferred 
labeling when displayed by a metadata aggregator. Appropriate cases include titles other 
than the primary title or subtitle. Include the text preferred and capitalization, but do not 
include delimiters such as colons. Metadata aggregators may choose to ignore this 
attribute. 

Sub-elements: 

<title> [REQUIRED] 

The <title> element contains the core title of the resource. At least one 
<titleinfo><title> is required by these guidelines. This element includes all parts of a 
title not covered by other sub-elements of <titleinfo>. 

<subTitle> [RECOMMENDED IF APPLICABLE] 

The <subTitle> element is used to record a part of a title deemed secondary to the core 
portion. The guidelines recommend the use of this element when a subtitle is present, 



6 http://www.loc.gov/marc/sourcecode/authoritvfile/authorityfilesource.html 

7 http ://www. loc . go v/marc/relators/relaothr.html#i'ela2 1 Ob 
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rather than including the subtitle in the text of the <t±tle> element. When using the 
<subTitle> element, do not include punctuation at the end of the <title> element 
intended to delineate the title from the subtitle. 

< P artNumber> [RECOMMENDED IF APPLICABLE] 

The <partNumber> element is used for a part or section number of a title. <partNumber> 
may describe the section of the digital object (for example, an episode number or an 
audio or video clip). <partNumber> may follow <title> or <subTitle> as appropriate. 
The guidelines recommend the use of this subelement when a part number is present, 
rather than including the part number in the text of the <title> element. When using the 
<partNumber> element, do not include punctuation at the end of the preceding element 
intended to delineate the part number from previous parts of the title. 

Multiple parts of an item should appear in separate MODS records or <relateditem> 
elements. 

< P artName> [RECOMMENDED IF APPLICABLE] 

The <partName> element is used for a part or section name of a title. Use <partName> to 
describe the section or division titles of the digital object (for example, a chapter title, 
episode name, or an audio or video clip). Multiple <partName> elements may be nested 
in a single <t±tleinfo> to describe a single part with multiple hierarchical levels (see 
the Bible example below); multiple parts, however, should be separated into multiple 
<titleinfo> elements. The guidelines recommend the use of this subelement when a 
part name is present, rather than including the part name in the text of the <t±tle> 
element. When using the <partName> element, do not include punctuation at the end of 
the preceding element intended to delineate the part name from previous parts of the title. 

Multiple parts of an item should appear in separate MODS records or <relateditem> 
elements. 

<nonSort> [RECOMMENDED IF APPLICABLE] 

The <nonSort> element contains characters, including initial articles, punctuation, and 
spaces that appear at the beginning of a title that should be ignored for indexing of titles. 
It should precede the <title> element when used. . The guidelines strongly recommend 
the use of this element when non-sorting characters are present, rather than including 
them in the text of the <t±tle> element. 

EXAMPLES OF <t±tleInfo> USE 

<titleInfo> 

<nonSort>The</nonSort> 

<title>01ympics</title> 

<subTitle>a history</subTitle> 

<partNumber>Part 1 </partNumber> 

<partName>Ancient</partName> 
</t±tleInfo> 
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<titleInfo displayLabel=" Supplied title" > 

<title>Genealogical information concerning several early families 

of Upper Indiana Presbyterian Church</title> 
</titleInfo> 

<titleInfo> 

<title>Life Mask of Stephen A. Douglas</title> 
</titleInfo> 

<titleInfo type=" uniform" author ity="naf"> 

<title>Bible</title> 

<partName>0. T. </partName> 

<partName>Exodus</partName> 
</titleInfo> 

USE BY AGGREGATORS 

<titleinfo> is the primary descriptive element used for identification and display for 
many digital objects. Most aggregators index <titleinfo> and will use it in a brief 
display. 

MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommends mapping the <titleinfo> element and all subelements to the <dc:title> 
element in simple Dublin Core. Since prescribed punctuation separating elements of the 
title is not included in MODS records prepared according to these guidelines, they would 
need to be inserted at the point of transformation. 

MODS examples above expressed in Dublin Core: 

<dc:title>The Olympics: a history. Part 1: Ancient</title> 

<dc:title>Genealogical information concerning several early 
families of Upper Indiana Presbyterian Church</title> 

<dc:title>Life Mask of Stephen A. Douglas</title> 

<dc:title>Bible. O.T. Exodus</title> 



RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

The Title Practices section in the DLF/NSDL Best Practices for Shareable Metadata 

Q 

discusses the use of titles. These guidelines are more prescriptive than the DLF/NSDL 
Best Practices, requiring at least one title be present in every record. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7TitlePractices 
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<name> 



MODS Element Attributes Subelements 

<namePart> 
<di spl ayForm> 
<affiliation> 
<role> 

<roleTerm> 
<description> 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records requires the 
use of at least one <name> element to describe the creator of the intellectual content of the 
resource, if available. The guidelines recommend the use of the type attribute with all 
<name> elements whenever possible for greater control and interoperability. In addition, 
they require the use of <namePart> as a subelement of <name>. This element is 
repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

The name of a person, organization, or event (conference, meeting, etc.) associated in 
some way with the resource. 

DISCUSSION OF USE 

Include as many <name> elements for contributors as are readily available. 9 For textual 
materials, include the names of all known authors, translators, and/or editors. For images, 
include the name of the creator of the original intellectual content (photographer, painter, 
architect, etc.) and the name of anyone capturing that content in a new medium (for a 
photograph of a building, include both the architect and the photographer). If the creator 
is unknown or anonymous, do not include "unknown," "anonymous," or a similar 
indication in the MODS records for aggregation. 

In addition to describing creators, <name> is used as a subelement of <subject>. For 
names used as subjects, see the <subject> section of the guidelines (see page 54). 

Repeat this element as necessary. 

Attributes: 

type [RECOMMENDED] 

The type attribute can take the following values: 

9 Do not be constrained by the Anglo-American Cataloging Rules, 2nd edition (AACR2) practice of 
limiting authors or contributors to three or fewer names. 



type 

<name> 

authority 
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personal 

corporate 

conference 

authority [RECOMMENDED] 

Use the form of a name taken from the authority file most appropriate to the resource and 
intended audience. The value for the authority attribute should come from the Source 
Codes for Name and Title Authority Files 10 maintained by the Library of Congress. Use 
the value local if a locally-developed name authority file is in use. If there is no name 
authority file in use, the authority attribute should not be used. 

Subelements: 

<namePart> [REQUIRED] 

The name itself is always wrapped in a <namePart> element. MODS allows for either 
breaking up parts of the name (given and family, for example) in different <namePart> 
elements or enclosing the entire name in one element. Use of the former method affords 
more control in sorting and display and should be used if the data is readily available. 
Either method is acceptable in these guidelines. 11 

Attribute of <namePart> 

type [RECOMMENDED IF APPLICABLE] 

When breaking a <name> element into constituent <namePart> elements, the type 
attribute should be used whenever applicable. This attribute takes the following 
values: 

date 

family 

given 

termsOf Address 
<displayForm> [OPTIONAL] 

The <displayForm> element makes it possible to display personal names in direct order 
rather than reversed. The element may be used if desired. 

<af filiation [OPTIONAL] 

This subelement contains the name, address, etc. of an organization with which the 
<name> entity was associated when the resource was created. If the information is readily 
available, it may be included. 

<role> [RECOMMENDED] 



http://www.loc.gov/marc/sourcecode/authoritvfile/authorityfilesource.html 
11 For greater interoperability, name elements should appear in the same order as those of their authorized 
form. If not authority is used, last name or family name should appear first, followed by a comma, followed 
by first or given names. 
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Use the <role> element as a wrapper element to contain coded and/or textual description 
of the role of the named entity. The guidelines recommend using this element primarily 
with personal names. Repeat <role> for each new role. These guidelines leave it up to 
the institution whether or not to generate "creator" as a <roleTerm>. 

Subelement for <roie> 

<roleTerm> [REQUIRED] 

Use this subelement to actually contain the coded or textual description. Both the 
coded and textual forms of the same role can be recorded in separate elements 
within a single <role> wrapper. 

Attributes for <roleTerm> 

type [RECOMMENDED] 

This attribute has two possible values. 

text - This value is used to express the role in a textual form 

code- This value is used to express the role in a coded form. The 
authority attribute should be used to indicate the source of the 
code. 

These guidelines recommend that, if <role> is used, that at least a textual 
version of the role is given using type="text". 

authority [RECOMMENDED IF APPLICABLE] 

Use this attribute to indicate the source if type="code". Use the values for 

12 

code authorities from the Source Codes for Relators and Roles 
maintained by the Library of Congress. At the time these guidelines are 
published there is only one: the MARC Value List for Relators and 
Roles 7J . 

<descri P tion> [NOT RECOMMENDED] 

Use this element to record a textual description of a name. Use of this subelement is not 
recommended in these guidelines. 

EXAMPLES OF <name> USE 

<name> 

<namePart>Whitman, Walt</namePart> 
<namePart type="date ">1819-1892</namePart> 
</name> 

<name authority="naf" type= "personal "> 

12 http://www.loc.gov/marc/sourcecode/relator/relatorsource.html 

13 http://www.loc.gov/marc/sourcecode/relator/relatorlist.html 
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<namePart>Evans, Walker, 1903-1 975</namePart> 
<role> 

<roleTerm type="code" 

authority= "marcrelator ">pht</roleTerm> 

<roleTerm type="text" author ity= "marcrelator ">Photographer 
</roleTerm> 
</role> 
</name> 

<name authority="naf" type= "personal "> 

<namePart type= "family ">Faulkner</namePart> 

<namePart type= "given ">William</namePart> 

<namePart type="date ">1897-1962</namePart> 
</name> 

<name authority="naf" type= "personal "> 

<namePart type= "family ">Mattox</namePart> 

<namePart type=" given ">Douglas E . </namePart> 

<namePart type= "given "> (Douglas Ernest ) </namePart> 

<namePart type="date ">1947-</namePart> 
</name> 

<name type= "corporate "> 

<namePart>Digital Library Federation</namePart> 
</name> 

USE BY AGGREGATORS 

Aggregators commonly use the <name> field as a target for author or subject searching. 
Even the simplest interfaces offer an author/creator search. In cases of unknown or 
anonymous creators of resources, aggregators generally remove values indicating this and 
rely on institutions' local records to convey this information if necessary. 

MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommend mapping <name><namePart> to either <dc : creator> or <dc : contributor 
in Dublin Core. The guidelines recommend mapping <name> elements to 
<dc : contributor as the default, but <dc : creator> may be used if you have source 
data that clearly identifies the name as creator. 

MODS examples above expressed in Dublin Core: 

<dc ; creator>Evans , Walker, 1 903-191 5</dc : creator> 

<dc: creator>Faulkner, William, 1897-1962</dc : creator> 

<dc: contributor>Mattox, Douglas E. (Douglas Ernest), 1947- 
</dc : contributor 

<dc:contributor>Digital Library Federation</dc : contributor 
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RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

The Name Practices section in the DLF/NSDL Best Practices for Shareable Metadata 
discusses the use of names. 14 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7NamePractices 
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<typeOfResource> 



MODS Element 


Attributes 


Subelements 


<typeOfResource> 


collection 
manuscript 


None 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require the 
use in all records of at least one <typeOfResource> element using the required 
enumerated values. This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

A term that specifies the characteristics and general type of content of the resource. 
DISCUSSION OF USE 

For the purposes of records created according to these guidelines, information in 
<typeOfResource> is about the original item. For example, in the case of a digitized 
photograph, <typeOfResource> would apply to the analog original; in born-digital 
materials, it would apply to the original digital format. 

The <typeOfResource> element is required by these guidelines and is used to categorize 
the resource at a fairly high level. <typeOfResource> has no subelements, but does 
require the use of an enumerated list of values. There are two possible attributes in 
addition to the common attributes described at the end of these guidelines [see page 100]. 

Repeat this element as necessary. 

Attributes: 

collection [RECOMMENDED IF APPLICABLE] 

Use this attribute (collection="yes") to indicate whether the resource described is a 
collection. A collection is defined as a multi-part group of resources. If there are multiple 
resource types within the collection, these should be enumerated in separate 
<typeOfResource> elements. 

manuscript [RECOMMENDED IF APPLICABLE] 

Use this attribute (manuscript="yes ") to indicate whether the resource described is 
handwritten or typescript. 

Values: 
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The values for <typeOfResource> are restricted to those in the following list. These 
should be used in accordance with the guidelines offered in the MODS User 
Guidelines. 15 

text 

cartographic 
notated music 

sound recording [if not possible to specify "musical" or "nonmusical"] 

sound recording-musical 

sound recording-nonmusical 

still image 

moving image 

three dimensional object 

software, multimedia 

mixed material 

EXAMPLES OF <typeOfResource> USE 

<typeOfResource>text</typeOfResource> 
<typeOfResource>still image</typeOfResource> 

<typeOfResource>cartographic</typeOfResource> 

<typeOf Resource collection= "yes ">text</typeOfResource> 

<typeOf Resource manuscript="yes ">text</typeOfResource> 

USE BY AGGREGATORS 

Due to its utility for determining research value (for example, a researcher looking 
specifically for cartographic material), aggregators may choose to include this field in a 
brief display to end users, and may also index it to allow limiting or refining by this data. 
Aggregators may also use this field to determine suitability for harvesting based on their 
perception of end users' needs. 

MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommend mapping <typeOfResource> to <dc:type>. In addition, these guidelines 
recommend that when mapping the values found in <typeOfResource> to Dublin Core 
Type values 16 , include both the MODS value and the DC value if they are substantially 
different. Similarly, the attributes of collection and manuscript should be included as 
an additional, separate <dc:type> value. 

<dc ; type>text </dc : type> 
<dc:type>still image</dc:type> 

<dc : type>cartographic</dc : type> 



http://www.loc.gOv/standards/mods/v3/mods-userguide-elements.html#typeofresource 
http://dublincore.org/documents/dcmi-type-vocabulary/ 
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<dc : type>St±llImage</dc : type> 

<dc : type>collection</dc : type> 
<dc : type>text </dc : type> 

<dc : type>manuscript </dc : type> 
<dc : type>text </ dc : type> 



RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

Related information is discussed in the Types of Resource and the Describing Versions 
and Reproductions 18 sections of the DLF/NSDL Best Practices for Shareable Metadata. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7TypesofResources 
http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7DigitalTactileResource 
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<genre> 



MODS Element 


Attributes 


Subelements 


<genre> 


authority 


None 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records recommend 
the use of at least one <genre> element in every MODS record and, if a value is 
provided, require the use of a value from a controlled list and the designation of this list 
in the authority attribute. This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

A term(s) that designates a category characterizing a particular style, form, or content, 
such as artistic, musical, literary composition, etc. <genre> contains terms that give more 
specificity than the broad terms used in <typeOfResource>. 

DISCUSSION OF USE 

The <genre> element is recommended in these guidelines and should be used to 
characterize the content of the digital resource rather than the digital resource itself. The 
values should be pulled from a controlled vocabulary appropriate for the resource 
described. This source vocabulary is indicated using the authority attribute. Consult 
Source Codes for Genre 19 , a list of possible controlled vocabularies and their source 
codes, maintained by the Library of Congress. 

Genre is a term that carries different specific meanings within different communities of 
practice, and the content of most information objects can be characterized by genre at 
some level of granularity, either very broad or quite specific. For example, photographs 
and ambrotypes are both valid genre characterizations, depending on your perspective, 
for a specific type of direct positive photographic print. At the very least, institutions can 
provide a very broad genre term for materials being digitized. Broad terms appear in 
many standard thesauri used for genre terms. For example: 'Books' appears in LCSH, 
AAT, and TGM II; 'Photographs' appears in all three as well; and 'Sound recordings' 
appears in LCSH and AAT. Values given should be as specific as possible within the 
context of an institution's descriptive program. It is recommended that institutions adopt a 
consistent, well-documented approach to supplying genre terms. 

Repeat this element as necessary. 

Attributes: 

authority [REQUIRED] 

19 http://www.loc.gov/marc/relators/relasour.html#rela655b 
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Use this attribute to indicate the controlled vocabulary used for the values in the <genre> 
element. 

EXAMPLES OF <genre> USE 

For a digital image of a Civil War era daguerreotype portrait: 

<genre authority="aat ">daguerreotypes</genre> 
<genre authority="aat ">portraits</genre> 

For a children's adventure story: 

<genre authority="gsafd">adventure f±ct±on</genre> 
<genre authority="lcsh">Children ' s literature</genre> 

USE BY AGGREGATORS 

For certain classes of materials with strongly developed genre vocabularies, the genre of 
an item is an important research tool; aggregators may choose to include this in the brief 
display. It may also be indexed to provide the option of limiting or refining searches 
using this data. Aggregators may also use the <genre> element to filter records 
appropriate for their service. 

MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommends mapping the <genre> element to the <dc : type> element in simple Dublin 
Core. 

MODS examples above expressed in Dublin Core: 

<dc : type>daguerreotypes</dc : type> 
<dc : type>portraits</dc : type> 

<dc : type> adventure fiction</dc : type> 
<dc : type>Children ' s literature</dc : type> 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

20 

Related information is discussed in the Types of Resource and the Describing Versions 
and Reproductions 21 sections of the DLF/NSDL Best Practices for Shareable Metadata. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7TypesofResources 
http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7DigitalTactileResource 
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<originlnfo> 



MODS Element 



Attributes 



Subelements 



<originInfo> 



encoding - date 
point - date 



keyDate - date 
qualifier - date 



type - <place> 
authority - <place> 



<place> 

<publisher> 

<datelssued> 

<dateCreated> 

<dateCaptured> 

<dateValid> 

<da t eModi fied> 

<copyrightDate> 

<dateOther> 

<edition> 

<issuance> 

<frequency> 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require the 
use of at least one <origininfo> element with at least one date subelement in every 
record, one of which must be marked as a key date. <place>, <publisher>, and 
<edition> are recommended if applicable. These guidelines make no recommendation 
on the use of the elements <issuance> and <frequency>. This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

Information about the origin of the resource, including place of origin or publication, 
publisher/originator, and dates associated with the resource. 

DISCUSSION OF USE 

Encode information in <origininfo> relevant to any version of a resource that is 
considered useful in an aggregated environment. It is usually not necessary to include full 
<origininfo> for every version of a resource known to exist; choose carefully which 
versions and elements it is important to share with aggregators. The examples given in 
these guidelines represent a sample of the types of decisions a metadata provider might 
make about which data is important to expose. 

Subelements: 

< P lace> [RECOMMENDED IF APPLICABLE] 

Record in <place> and its subelement <placeTerm> place names associated with the 
creation or issuance of a resource. Follow the MODS User Guidelines for the structure 
and use of repeated <place> elements and <placeTerm> subelements. Descriptive 
standards such as AACR2 may be used to determine which places to record for published 
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resources. For unpublished resources, if a place of origin is known, record it in 
<place><place Term> . 

The <place> and the <placeTerm> subelement should be omitted if no information about 
the originating place of the resource is known. 

Repeat <place> for recording multiple places. 

Subelement for <piace> 

<placeTerm> [REQUIRED] 

Use the <placeTerm> subelement to record the textual or code form of the place. 
Attributes for <placeTerm>: 
type [REQUIRED] 

This attribute may be used with the following values: 

text - This value is used to express place in a textual form 

code - This value is used to express place in a coded form. The authority 
attribute may be used to indicate the source of the code. 

For each <placeTerm> given, the guidelines require including, at a minimum, a 
textual version of the place, with the attribute type="text ". 

authority [RECOMMENDED IF APPLICABLE] 

Appropriate values for this attribute may be found in the MODS User Guidelines. 

If the place given is a country, and the name of that country has been selected 
from the MARC country code list or the IS 03 166 standard list of country names, 
add an authority attribute to <placeTerm> indicating the source of the country 
name, and add a second <placeTerm> subelement within <place> indicating the 
coded version of that country name from the chosen authoritative list, with the 
attribute type="code" and an authority attribute indicating the source of the 
country code. 

<publ±sher> [RECOMMENDED IF APPLICABLE] 

Record in <publisher> a named entity determined to be the publisher or originator for a 
resource. Descriptive standards such as AACR2 may be used to format the name of the 
publisher. Information about an institution responsible for digitizing and delivering 
online a previously published resource should be included in <note>, rather than 
<or±ginInfo><publisher>. 

There are no attributes for the <publ±sher> element. 

dates [AT LEAST ONE DATE ELEMENT IS REQUIRED] 
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The MODS schema includes several date elements intended to record different events 
that may be important in the life of a resource. 

The following date elements are recommended for use by these guidelines. Record dates 
for as many of these MODS elements as is appropriate. To indicate to aggregators which 
is the best date to use for sorting and similar features, mark one and only one date as a 
key date using keyDate="yes" attribute. Institutions may choose to use only one date 
element when several apply but would contain identical data. 

<dateissued> - publication or issued date 

<dateCreated> - date of creation of the resource 

<copyr±ghtDate> - date on which a resource is copyrighted 

<dateOther> - generic date element that does not fall into another category but is 

important to record 

The guidelines recommend recording each date in a structured form rather than a textual 
form. When a date is uncertain or cataloger-supplied, indicate this through the use of the 
qualifier attribute (described below) rather than inserting characters such as "ca.", 
brackets or a question mark as part of the date string. When only a decade is known, enter 
a date range for the entire decade and mark the date as questionable. When only a century 
is known, enter a date range for the entire century and mark the date as questionable. 

Two date encoding formats from the cultural heritage community may be used for 

22 23 

encoding BCE dates: TEMPER and EDTF . As neither of these encoding formats is 
currently an option for the MODS date encoding attribute, do not include an encoding 
attribute if one of these formats is used. 

The following date elements are not recommended for use. In some cases they may be 
considered technical metadata, and would not generally be used by aggregators to 
provide access to a resource: 

<dateCaptured> - date on which the resource was digitized or a subsequent snapshot 
was taken 

<dateval±d> - date in which the content of a resource is valid 
<dateModified> - date in which a resource is modified or changed 

Attributes for date elements: 

The attributes below apply to all MODS date elements. 
encoding [RECOMMENDED] 

If an exact year is known, the guidelines recommend representing the value using 
the W3CDTF encoding, which also allows month and day to be specified if 
known. The W3CDTF encoding is a profile of the more flexible ISO8601 
standard. Using W3CDTF ensures a more predictable format for dates. These 



http://tools.ietf.org/html/draft-kunze-temper-01 
http://www.loc.gov/standards/datetime/ 
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guidelines recommend using ISO8601 encoding only when a date cannot be 
expressed using W3CDTF. 

point [RECOMMENDED IF APPLICABLE] 

The point attribute is used to specify whether a date is a start date or an end date if 
the resource is best described by a date range. Best practice is to use the point 
attribute only when a date range is indicated, not for single dates. 

keyDate [REQUIRED IN ONE AND ONLY ONE DATE ELEMENT] 

Every MODS record containing at least one date should have one and only one 
date element with the attribute keyDate="yes". The key date will be used by 
aggregators for date indexing, sorting, and display. The date marked as the key 
date should be the date considered by the metadata provider as the most important 
for end user access. Frequently this will be the date the item was created or 
issued. Even if only one date is present in a MODS record, including the keyDate 
attribute on that date element provides a significant benefit to the aggregator. 
Metadata provider processing strategies are much more likely to be able to add 
this attribute easily than an aggregator is to locate and act upon the correct date, 
even if only one date is present in the MODS record. For date ranges, mark the 
start date of the range intended for date searching as the keyDate. 

qualifier [RECOMMENDED IF APPLICABLE] 

The qualifier attribute has three allowed values: approximate, inferred, and 
questionable. Best practice is to use this attribute with the appropriate value 
when a date is approximate, inferred, or questionable, rather than inserting 
characters such as "ca.", brackets or a question mark within the date string. 

<edition> [RECOMMENDED IF APPLICABLE] 

The <edition> element is used to provide an edition statement for a published work. 
Descriptive standards such as AACR2 and DACS may be used to determine if an edition 
statement should be recorded and in what format. If no edition statement applies to the 
resource, do not include the <edition> element. 

<issuance> [OPTIONAL] 

These guidelines offer no specific guidance on the use of <issuance>. 
<frequency> [OPTIONAL] 

These guidelines offer no specific guidance on the use of <frequency>. 
EXAMPLES OF <or±g±nInfo> USE 

<originInfo> 
<place> 

<placeTerm type="text">New York</placeTerm> 
</place> 
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<publ i sh&r>Ma cMi 11 an </publ ±sher> 
< copy right Date encoding="w3cdtf" keyDate="yes" 
qualifier=" inferred" >1922</copyrightDate> 
<edition>2nd ed. </edition> 
</originInfo> 

<originInfo> 

<dateCreated encoding="w3cdtf" keyDate="yes" 
qualifier=" approximate " point=" start ">1857</dateCreated> 
<dateCreated encoding="w3cdtf" qualifier=" 'approximate" 
point=" end" >1860</ dateCreated> 

</originInfo> 

<originInfo> 

<dateCreated encoding="iso8601" keyDate="yes" 

qualifier=" inferred" >1 6</dateCreated> 
</originInfo> 

<originInfo> 
<place> 

<placeTerm type="text ">Sumeria</placeTerm> 
</place> 

<dateCreated keyDate= "yes " qualifier= "approximate ">2500 
BCE</da t eCrea t ed> 
</originInfo> 

<originInfo> 
<place> 

<placeTerm type= "code " 

author ity="marccountry">enk</placeTerm> 
<placeTerm type="text ">England</placeTerm> 
</place> 

<datelssued encoding="w3cdtf" keyDate="yes" 
qualifier=" inferred" >1855</datelssued> 
<issuance>monographic</issuance> 
</originInfo> 

USE BY AGGREGATORS 

Aggregators in the current environment will likely use dates for providing access to 
materials by their creation date, including limiting searches to resources created within a 
certain date range, or browsing by the date of creation of a resource. The keyDate 
attribute signifies to an aggregator which date is most important, but aggregators should 
also make use of indication of date ranges, uncertain dates, and the like to improve end 
user discovery. Other dates and other <origininfo> data would likely be displayed to a 
user, to give that user the information he or she needs to determine if the resource is of 
interest. 

MAPPING TO DUBLIN CORE 

As the MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
makes clear, subelements of <origininfo> map incompletely to Dublin Core elements. 
The MODS element <publisher> maps to <dc: publishers and all of the date elements 
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to <dc:date>. If multiple dates are present in the MODS record, data providers may want 
to consider mapping only the date indicated as the keyDate to the <dc:date> element. 

The MODS elements <place>, <edition>, <issuance>, and <frequency> do not map 
directly to simple Dublin Core elements. However, a <place> element in combination 
with a <publisher> element may be combined to map to <dc:publisher> following 
the AACR2 convention. 

MODS examples above expressed in Dublin Core: 

<dc :publisher>New York: MacMillan</dc :publisher> 
<dc : date>l 922</dc : date> 

<dc : date>1857-1860</dc : date> 

<dc : date>l 6</dc : date> 

<dc:date>2500 B.C.E.</dc:date> 

<dc : date>1855</dc : date> 



RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

The Date Practices section of the DLF/NSDL Best Practices for Shareable Metadata 

24 

discusses the use of dates . Other elements in <origininfo> are not covered in the 
DLF/NSDL Best Practices for Shareable Metadata. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7DatePractices 
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<language> 



MODS Element 


Attributes 


Subelements 




type - <languageTerm> 






authority - 




<language> 


<languageTerm> 


<languageTerm> 




objectPart - 






<languageTerm> 





SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require at 
least one <language> element for all resources in which language is primary to 
understanding the resource. These resources include textual resources, as well as audio 
and video resources with spoken word components. Although <language> is usually not 
required for non-textual resources such as images, it could be used effectively for such 
resources when language is a primary component. Examples of the latter might include a 
photograph of a sign with text or a monument with an inscription. This element is 
repeatable. 

DEFINITION FROM MODS USER GUIDELINES 25 

A designation of the language in which the content of a resource is expressed. 
DISCUSSION OF USE 

<language> is a wrapper element for one or more <languageTerm> elements. At least 
one <language> element is required for resources in which language is primary to 
understanding the resource. The <language> element is optional for resources in which 
language is important to understanding the resource, but not primary. For example, the 
caption of a photograph may in some instances be important to understanding the 
photograph, but not primary. Whether to include a <language> element based on the 
language's importance or primacy is left to data provider's discretion. Repeat the 
<language> element as necessary. 

Attribute: 

objectPart [OPTIONAL] 

This attribute designates which part of the resource is in the language supplied. For 
example,<language objectPart=" summary" authority="iso639-2b">spa</language> 
indicates that only the summary is in Spanish. The values of the attribute are not 
controlled, although it is preferable that institutions use consistent forms. 



http://www.loc.gov/standards/mods/v3/mods-userguide-generalapp.html 
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Subelements: 

<languageTerm> [REQUIRED] 

This repeatable subelement contains the language of the content of the resource in coded 
and textual form. These guidelines require at least one pair of <languageTerm> elements 
representing the primary language of the text wrapped in a single <language> element. 
One of these <languageTerm> elements should carry the attribute type="text " and the 
other should have type="code". Additional pairs of <languageTerm> elements 
representing secondary languages may be included in separate <language> elements. 

Attributes for <languageTerm> 

type [REQUIRED] 

This attribute may contain the following values: 

text - The value of this attribute is the name of the language of the electronic 
resource in text form. Use the form of the language found in the MARC Code List 
for Languages. 26 

code - The value of this attribute is the three-character alphabetic code found in 
iso639-2b, a bibliographic language code from ISO 639-2 (Codes for the 
representation of names of languages: alpha-3 code) , which is identical to the 
MARC Code List for Languages. 27 

authority [REQUIRED IF APPLICABLE] 

These guidelines require using the value ±so639-2b for this attribute in the 
<languageTerm> element that contains the attribute type="code". Do not use an 
authority attribute in the <languageTerm> element that contains the attribute 
type="text ". 

EXAMPLES OF <language> USE 

<language> 

<languageTerm type="text ">French</languageTerm> 
<languageTerm type="code" authority="iso639- 
2b ">fre</languageTerm> 
</language> 

<language> 

<languageTerm type="text" 

objectPart=" caption ">English</languageTerm> 

<languageTerm type="code" objectPart=" caption" authority="iso639- 
2b ">eng</ 1 anguage Term> 



http://www.loc.gov/marc/languages/ 
27 See MODS User Guidelines (http://www.loc.gov/standards/mods/v3/mods-userguide- 
elements.html#language) and the ISO 639b FAQ (http://www.loc.gOv/standards/iso639-2/faq.html#3) for 
further information. IS0639-2b is "A bibliographic language code from ISO 639-2 (Codes for the 
representation of names of languages: alpha-3 code)." 
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</language> 

USE BY AGGREGATORS 

<language> is a primary descriptive element and is used for narrowing search results. 
MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommends mapping the contents of the <language> element to <dc : language>. These 
guidelines further recommend mapping each subelement <languageTerm> to a distinct 
<dc : language> element. 

MODS examples above expressed in Dublin Core: 

<dc ; language>French</dc : language> 
<dc : language>fre</dc : language> 

<dc : language>English</dc : language> 
<dc : language>eng</dc : language> 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

Language is discussed as a general class of element in the "Language" section of the 

28 

DLF/NSDL Best Practices for Shareable Metadata. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7LanguagePractices 
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<physicalDescription> 



MODS Element 



Attributes 



Subelements 



type - <form> & <note> 
<physicalDescr±ption> authority - <form> 

displayLabel - <note> 



<form> 

<reformatt±ngQual±ty> 

<internetMediaType> 

<extent> 

<d±g±talOr±g±n> 

<note> 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require the 
use of one <phys±calDescrlptlon> element, one subelement <dig±talOrig±n>, and at 
least one subelement <internetMedlaType>. This element is not repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

<phys±calDescription> is a wrapper element that contains all subelements relating to 
physical description information of the resource described. 

DISCUSSION OF USE 

Encode information in <physicalDescr±pt±on> relevant to any version of a resource 
that is considered useful in an aggregated environment. It is usually not necessary to 
include a full <physicalDescr±pt±on> for every version of a resource known to exist; 
choose carefully which versions and elements it is important to share with aggregators. 
The examples given in these guidelines represent a sample of the types of decisions a 
metadata provider might make about which data is important to expose. 

Subelements: 

<f orm> [RECOMMENDED] 

This subelement specifies the physical form or medium of the material for a resource. 
Record the form of digitized and analog original resources if such information will be 
useful to aggregators. 

Attributes of <form> 

type [NOT RECOMMENDED] 

The attribute type may be used to specify whether the form concerns materials or 
techniques, for example type= "material": oil paint; type="technique": painting. 
However, there are no controlled values for the type attribute. Use of uncontrolled 
values - particularly within attributes - have limited usefulness for aggregators. 
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authority [RECOMMENDED] 

Use the authority attribute to specify the source of the controlled value recorded. A 
list of possible authorities is available at Source Codes for Forms 29 maintained by the 
Library of Congress. 

<reformattingQuality> [OPTIONAL] 

This subelement reflects an overall assessment of the quality of the digital resource. It has 
no attributes. The values available in MODS for this subelement (access, 
preservation, replacement) reflect information useful in local environments, but not 
for the purposes of metadata aggregation. Aggregators are unlikely to benefit from the 
inclusion of this subelement in shared metadata records. 

<internetMediaType> [REQUIRED] 

This subelement records the electronic format type of the digital resource. Since it is 
expected that records shared for the Aquifer initiative describe resources existing in 
digital versions, at least one <internetMediaType> is required. This element has no 
attributes. 

Inclusion of an <internetMediaType> is a key feature of a shared metadata record to 
enable aggregators to provide added value on resources themselves rather than only on 
metadata and is therefore critical to the continued growth of aggregation services. While 
adding this information to source metadata from which MODS records are generated (if 
MODS is not the native format) is desirable, this is not always feasible. A second option 
for institutions that do not have the resources to revisit legacy metadata is to adjust 
stylesheets or other MODS generation code to add this data to generated records en 
masse. 

The content value for this subelement should be taken from the MIME Media Types list 

OA 

and expressed in the format type/subtype . If a digital resource comprises multiple file 
types (for example, a diary that has been imaged and a text transcription made available), 
use a separate <intemetMediaType> subelement for each. 

<extent> [RECOMMENDED IF APPLICABLE] 

This subelement includes a statement of the number and specific material of the units of 
the resource that express physical extent. It has no attributes. 

The use of your content standard of choice is strongly recommended if this subelement is 
used. 

<digitalOrigin> [REQUIRED] 

Record here the method by which a resource achieved digital form. Content values for 
this subelement are defined in the MODS schema. Current options are: bom digital, 

29 http://www.loc.gov/marc/sourcecode/form/formsource.html 

30 http://www.iana.org/assignments/media-types/index.html 
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reformatted digital, digitized microfilm, and digitized other analog. 

Resources incorporating pre-existing analog content with new digital content should be 
recorded as "born digital". This subelement has no attributes. 

<note> [RECOMMENDED IF APPLICABLE] 

This subelement contains notes relating to the physical description of a resource that do 
not fit in one of the other available subelements. A separate <note> subelement should be 
used for each distinct note. Documentation on material and technique used for works of 
art and similar materials may be recorded here. 

Attributes of <note> 

type [NOT RECOMMENDED] 

There are no controlled values for the type attribute. Use of uncontrolled values have 
limited usefulness for aggregators. 

displayLabel [OPTIONAL] 

The displayLabel attribute may be used to indicate the preferred labeling when 
displayed by a metadata aggregator. However, metadata aggregators may choose to 
ignore this attribute. 

EXAMPLES OF <physicalDescription> U SE 

For a digitized photograph: 

<physicalDescription> 

<form author i ty= " smd " >ph o t opri n t </form> 
<form authority= "marcform ">electronic</form> 
<internetMediaType>image/ jpeg</ internetMediaType> 
<extent>l photograph</ extent > 

<digitalOrigin>re formatted digital</digitalOrigin> 
</physicalDescription> 

For a diary that has been imaged and for which a text transcription has been made: 

<physicalDescript ion> 

<form authority= "marcform ">electronic</form> 
<form author i ty= "marcform ">print</ form> 
<internetMediaType>image/jpeg</internetttediaType> 
<internetMediaType>text/xml</internetttediaType> 
<extent>177 p.</extent> 

<digitalOrigin>re formatted digital</digitalOrigin> 
</physicalDescription> 

For a learning web site: 

<physicalDescript ion> 

<form authority= "marcform ">electronic</form> 
<internetMediaType>image/ jpeg</ internetMediaType> 
<internetMediaType>text/html</internetttediaType> 
<extent>5 digital files</extent> 
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<digitalOrigin>born d±g±tal</digitalOrigin> 
</physicalDescription> 

USE BY AGGREGATORS 

Information in <±nternetMed±aType>, and possibly <form> may be used by aggregators 
to limit searches to particular types of resources or to offer browsing. Other information 
in <physicalDescr±pt±on> would generally be used in the record display. 

MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping, Version 3.0 (June 7, 2005) 
recommend mapping <physicalDescript±on>, <form>, <extent>, and 
<internetMedlaType> to <dc:format>. These guidelines also recommend mapping 
<digitalOr±gin> to <dc:format>. Each value should be mapped to a separate instance 
of the <dc : format> element. 

MODS example above expressed in Dublin Core: 

<dc ; format>electronic</dc : format> 

<dc : format> image / jpeg</dc : format> 

<dc : format>l photograph</dc : format> 

<dc : format>re formatted digital</dc : format> 

<dc : format>electronic</dc : format> 

<dc: forma t >pri n t </dc : f or ma t > 

<dc : format> image / jpeg</dc : format> 

<dc : format>text/xml </dc : format> 

<dc : format>l 77 p. </dc : format> 

<dc : format >re formatted digital</dc : format> 

<dc : format>electronic</dc : format> 
<dc : format> image / jpeg</dc : format> 
<dc : format>text/html</dc : format> 
<dc:format>5 digital files</dc : format> 
<dc: forma t >born digital </dc : f orma t > 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

Physical description is not explicitly covered in the DLF/NSDL Best Practices for 
Shareable Metadata. However, portions of the Types of Resources 31 and Describing 
Versions and Reproductions sections may be applicable. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7TypesofResources 
http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7DigitalTactileResource 
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<abstract> 



MODS Element 


Attributes 


Subelements 


<abstract> 


type 


none 


di spl ayLabel 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records recommend 
the use of one <abstract> element in every MODS record, except when a title, formal or 
supplied, serves as an adequate summary of the content of the digital resource. This 
element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

A summary of the content of the resource. 
DISCUSSION OF USE 

Record a succinct summary of the content of the digital resource. When creating a 
MODS record for a digital surrogate, record a summary of the content of the original 
resource. If only a portion of the resource was digitized, summarize only that portion. 
This element provides end users with information about the digital resource that assists 
them in making a judgment about its likely usefulness, and also provides context, if 
needed, for controlled vocabulary used in the record. The use of your content standard of 
choice is strongly recommended. 

This element may be repeated as necessary. 

Attributes: 

type [NOT RECOMMENDED] 

There are no controlled values for the type attribute. Use of uncontrolled values - 
particularly within attributes - have limited usefulness for aggregators. 

displayLabel [OPTIONAL] 

The displayLabel attribute may be used to indicate the preferred labeling when displayed 
by a metadata aggregator. However, metadata aggregators may choose to ignore this 
attribute. 

EXAMPLES OF <abstract> USE 

<abstract>Depicts stationery store and other buildings in San 
Francisco, California . </abstract> 
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<abstract> Broadside advertising a funeral ceremony commemorating 
assassinated president Abraham Lincoln, held in Elgin, Illinois, on 
April 19, 1865. It details the route of the procession, the order of 
local official participants in the procession, and the order of service 
for the ceremony to be held in the Academy Hall . </abstract> 

MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommends mapping <abstract> to <dc: description. 

MODS examples above expressed in Dublin Core: 

<dc:description>Depicts stationery store and other buildings in 
San Francisco, Calif ornia.</dc:description> 

<dc:description> Broadside advertising a funeral ceremony 
commemorating assassinated president Abraham Lincoln, held in 
Elgin, Illinois, on April 19, 1865. It details the route of the 
procession, the order of local official participants in the 
procession, and the order of service for the ceremony to be held 
in the Academy Hall . </dc : description> 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

Abstract as a broad class of elements is not covered in the "Recommendations for classes 
of data elements" in the DLF/NSDL Best Practices for Shareable Metadata. 
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<tableOfContents> 



MODS Element 


Attributes 


Subelements 


<t abl eOfCon tents> 


type 


none 


di spl ayLabel 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records recommend 
the use of the <tableOfContents> element when applicable. This element is not 
repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

A description of the contents of a resource. 
DISCUSSION OF USE 

Use of <tableOfContents> should be determined by the complexity of the digital object 
and whether or not the information is readily available. If more structured information is 
needed, consider using <relateditem> with the type=" constituent " attribute instead 
(see page 66). MODS also allows for <tableOfContents> to be used as an empty 
element with an xlink -.href attribute to link to an external table of contents. Either 
method is supported by these guidelines. 

Attributes: 

type [NOT RECOMMENDED] 

There are no guidelines and no controlled vocabulary for this attribute. Use of 
uncontrolled values - particularly within attributes - have limited usefulness for 
aggregators. 

displayLabel [OPTIONAL] 

The displayLabel attribute may be used to indicate the preferred labeling when 
displayed by a metadata aggregator. Include the text preferred and capitalization, but do 
not include delimiters such as colons. Metadata aggregators may choose to ignore this 
attribute. This attribute can be used whenever necessary to explain more about what is 
contained in the <tableOfContents>. Examples include Partial Contents, List of 
Photographs, or Chapters. 

xlink [RECOMMENDED IF APPLICABLE] 

This attribute may be used to link to an external table of contents. 
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EXAMPLES OF <tableOfContents> USE 

<tableOf Contents displayLabel="Partial Contents ">Honey Boy - Hiawatha 
Song - Her Boy in Blue</tableOf Content s> 

<t abl eOfCon tents 

xlink :href= "http : //www. ojp . usdoj . gov/bjs/toc/cchrie98 . htm "/> 

MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommends mapping <tableOfContents> to the <dc : description element. 

MODS example above in Dublin Core: 

<dc : description>Honey Boy - Hiawatha Song - Her Boy in 
Blue</dc : description> 

<dc : description>http : //www. ojp . usdoj . gov/bjs/toc/cchrie98 . htm</dc 
: description 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

The DLF/NSDL Best Practices for Shareable Metadata do not cover Table of Contents 
as a broad class of element. 
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<targetAudience> 



MODS Element 


Attributes 


Subelements 


<t argetAudi en ce> 


authority 


none 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records recommend 
the use of at least one <targetAud±ence> element when applicable, and a controlled 
vocabulary when available. This element is repeatable. 



A description of the intellectual level of the audience for which the resource is intended. 
DISCUSSION OF USE 

Use <targetAudience> to describe a group for which a resource is intended. Use this 
element whenever there is a specific audience for a resource (for example, a text marked 
up specifically for historians). Note that these guidelines do not limit the use of the 
<targetAudience> element to the intellectual level of the audience. Use the authority 
attribute whenever possible to indicate the controlled vocabulary used (see below for a 
caveat). 

Do not use <targetAudience> to indicate audiences to whom access or use of the 
resource is limited; include this information in the <accessCondition> element (see 
page 82). 

Attribute: 



authority [Recommended if applicable] 

Use this attribute to indicate the controlled vocabulary in use. These guidelines recognize 
that the "Source Codes for Target Audience" maintained by the Library of Congress 
contains only one source code, marctarget, 34 which itself contains a very limited set of 
values. If this source is not of use, these guidelines recommend that the value of the 
<targetAudience> be expressed clearly and be generally understandable outside of the 
local context of the resource. 

EXAMPLE OF <targetAudience> USE 

<targetAudience authority= "marctarget ">specialized</targetAudience> 
<targetAudience>Genealogists</targetAudience> 



33 http://www.loc.gov/marc/sourcecode/target/targetsource.html 

34 http://www.loc.gov/marc/sourcecode/target/targetlist.html 
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<targetAudience>English as a second language (ESL) 
st udents</t argetAudi ence> 

USE BY AGGREGATORS 

Aggregators may use this field to separate out content to audiences of differing 
intellectual interests and levels. This is not currently common practice. 

MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
does not provide a mapping for <target Audience >. 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

The DLF/NSDL Best Practices for Shareable Metadata do not discuss audience as a 
general class of elements. 
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<note> 



MODS Element 


Attributes 


Subelements 


<note> 


type 


none 


di spl ayLabel 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records recommend 
using <note> if applicable. This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

General textual information relating to a resource. 
DISCUSSION OF USE 

<note> should be used only for information that cannot be encoded in another, more 
specific MODS element. For example, in retrospective conversion of existing MARC 21 
records, many 5XX note fields, while technically falling within the definition of the 
<note> element above, should be mapped to more specific MODS elements. Also, not all 
notes in existing MARC 21 records provide information about the intellectual content of 
the resource described; these need not be mapped into the MODS record. In an OAI- 
PMH environment, where end users will be directed by service providers back to the 
original institution's site and a complete metadata record for access, <note> content that 
is not about the content of the resource may not need to be included in the MODS record 
made available for harvesting. Several examples, using MARC 21 and EAD, of mappings 
to more specific MODS elements than <note> are given in the chart below: 



MARC 
21 field 


EAD element 


Type of content 


More specific MODS 
mapping 


501 


Nested <c01>, 
<c02>, etc. 


Indicates that the item being 
described is physically part of 
a larger entity. 


<relatedltem type="host"> 
<note> 


506 


<accessrestrict> 


Indicates restrictions on 
access. 


<accessCondltlon> 


520 


<scopecontent> 


A summary describing the 
scope and general contents of 
the item being described. 


<abstract> 


521 


N/A 


The specific audience or 
intellectual level for which the 
content of the described item 
is considered appropriate. 


<targetAudience> 
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530 


<altformavail> 


Identifies additional physical 
form(s) in which the described 
item is available. 


<relatedltem 

type= "otherFormat "> 

<note> 


534 


<originalsloc> 


Describes the original version 
when the described item is a 
surrogate or reproduction. 


<abstract> 


535 


<originalsloc> 
OR 

<altformavail> 


Indicates the name and 
address of the repository that 
has custody of the original or a 
duplicate copy of the 
described material when either 
is housed in a repository 
different from that of the 
material being described 


<locat±on> 
<physicalLocatlon> 


546 


<langmaterial> 


Textual information on the 
language of the described 
materials. 


<language> 



Attributes: 

type [OPTIONAL] 

There are no guidelines and no controlled vocabulary for this attribute. Use of 
uncontrolled values - particularly within attributes - have limited usefulness for 
aggregators. 

displayLabel [OPTIONAL] 

The displayLabel attribute may be used to indicate the preferred labeling when 
displayed by a metadata aggregator. Include the text preferred and capitalization, but do 
not include delimiters such as colons. Metadata aggregators may choose to ignore this 
attribute. 

EXAMPLES OF <note> USE 

<note>Based on the play "I am a camera" by John Van Druten, and "Berlin 
stories" by Christopher Isherwood. </note> 

<note>Thesis (M.A.) — Yale University, 1974 . </note> 

<note displayLabel= "Visual characteristics ">Medium range shot, vertical 
compos it ion< /not e> 

<note>170 of the 177 pages of the original have been digitized. 
Prefaces and appendices were excluded. </note> 

<note>Digital file includes a piano score composed and performed by 
Philip Carli . </note> 

<note>Perspective map not drawn to scale . </note> 
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USE BY AGGREGATORS 



Aggregators may choose to index and display content in <note> directly to end users. 
However, there is no requirement or obligation for them to do so. Therefore, the <note> 
field should not be relied upon to communicate information, critical to use or access, that 
is better suited for other fields. 



MAPPING TO DUBLIN CORE 



The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommend mapping each <note> element to a <dc : description element. 

MODS examples above expressed in Dublin Core: 

<dc:description>Based on the play "I am a camera" by John Van Druten, 
and "Berlin stories" by Christopher Isherwood. </dc : description> 

<dc:description>Thesis (M.A.) — Yale University, 1974 . </dc : description> 

<dc:description>Medium range shot, vertical 
composition</dc: description> 

<dc:description>170 of the 177 pages of the original have been 
digitized. Prefaces and appendices were excluded. </dc: description 

<dc:description>Digital file includes a piano score composed and 
performed by Philip Carli . </dc: description 

<dc:description>Perspective map not drawn to scale. </dc: description 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

Notes as a broad class of elements are not covered in the Best Practices for Shareable 
Metadata. 
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<subject> 



MODS Element 



Attributes 



Subelements 



authority 

encoding - <temporal> 
point - <temporal> 
keyDate - <temporal> 
type - <titleInfo> 
authority - 



<topic> 
<geographi c> 
<temporal> 
<titleInfo> 



<name> 



<subject> 



<titleInfo> 
displayLabel - 



<genre> 

<hierarchi calGeographic> 
<cart ographi cs> 
<geographi cCode> 
<occupation> 



<titleInfo> 
type - <name> 
authority - <name> 
authority - 



<geographi cCode> 



SUMMARY OF REQUIREMENTS 

The DLF /Aquifer Implementation Guidelines for Shareable MODS Records require, 
when applicable, the use of at least one <subject> element in a record. Values for 
<subject> indicate what content is found within or represented by the work, and 
typically answer such questions as who, what, where, and when. 35 These guidelines 
highly recommend the use of subject values from a controlled list and the designation of 
this list in the authority attribute. Parsing subject values into subelements, rather than 
placing them in <subject><topic> strings, is not required but is highly recommended, 
when possible. Repeat distinct, multiple subjects in separate <subject> fields. 

DEFINITION FROM MODS USER GUIDELINES 

A term or phrase representing the primary topic(s) on which a work is focused. 
DISCUSSION OF USE 

For the purposes of records created according to these guidelines, information in 
<subject> describes subject content represented in or by the work, and typically answers 
such questions as who, what, where, and when. 

Whether or not the use of <subject> is applicable depends upon who might search for an 
item outside its local context and how they are likely to search for it. For instance, topical 
subject content may not apply to some items, such as abstract art. If researchers are likely 
to be interested in the form or genre of an item, and not its subject content, using the 



The discussion of subjects in Descriptive Metadata Guidelines for RLG Cultural Heritage Materials 
guides much of this understanding of subject content: http://www.rlg.org/en/pdfs/RLG desc metadata.pdf . 
Description of subject content may not be applicable to some works; in those cases, use of a <subject> 
element is not required. See "Discussion of Use" for more information on the appropriate use of this 
element. 
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<genre> element (not the subelement under <sub ject>) may be most appropriate. 
However, in many instances, using appropriate <subject> values can greatly enhance 
users' ability to locate relevant works. Enter as many specific terms as necessary to 
capture subject content, and be consistent in the formatting of subject terms. 

It is highly recommended that subject terms come from a controlled vocabulary or formal 
classification scheme and that this source is identified in the authority attribute. Select 
controlled vocabularies that are most relevant to and frequently used by the communities 
likely to benefit from the described materials, and explicitly identify this source. If a 
subject term is appropriate or well-known among a group of users, and it is not included 
in a formal classification scheme, it may still be included, but the source of the term 
should be identified. Place any locally-developed vocabulary term in a separate 
<subject> group and define its authority as local. If the term is not controlled by a 
formal classification scheme or a locally developed scheme, authority is not defined. New 
subject authorities can be registered with the Library of Congress; email ndmso@loc.gov 
to suggest an authority. 

As described below, subelements within <subject> are used to differentiate subject 
content. While MODS does allow for placing multiple values in a single 
<subject><top±c> string, parsing subject terms into separate subelements is the 
preferred practice and highly recommended in these guidelines. Express multiple subjects 
in repeated <subject> fields. 

Attributes: 

authority [RECOMMENDED IF APPLICABLE] 

The name of the authoritative list for a controlled value is recorded here. An authority 
attribute may also be used to indicate that a subject is controlled by a record in an 
authority file. Authority should be specified for all terms, whether they come from a 
controlled vocabulary, formal scheme, or are locally developed. The authority attribute 
for a locally-developed scheme should be defined as authority=" local". If no list or 
scheme controls the terms used, omit the authority attribute. 

Specify authority at the <subject> level in most cases (exceptions are 
<subject><name>, <subject><titleInfo>, and <subject><geographicCode>). If 
providing subjects from different authorities, use a separate <subject> element for each. 
This is required even when subjects differ only at the subelement level. 

Subelements: 

<to P ic> [RECOMMENDED IF APPLICABLE] 

Use this subelement to indicate any primary topical subjects that are not appropriate in 
the <geographic>, <temporal>, <titleinfo>, or <name> subelements. While it is 
highly recommended that subject values be parsed into subelements, they may also be 
listed as a string under <subject><topic>. This subelement has no attributes. 
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If a controlled subject term is used, indicate authority using the authority attribute at 
the <subject> level. Locally developed terms should be listed separately, with local 
indicated as the source using the authority attribute at the <subject> level. If the term 
is uncontrolled (for example, if it is a keyword from legacy records), do not use the 
authority attribute. 

<geogra P hic> [RECOMMENDED IF APPLICABLE] 

Use this subelement for geographic subject terms that are not parsed within the 
<hierarchicalGeographic> element (see below). If the geographic name is part of a 
corporate body (for example, United States. Senate), it is coded as <name>, not 
<geographic>. This subelement has no attributes. 

If a controlled subject term is used, indicate authority using the authority attribute at 
the <sub ject> level. 

<tem P oral> [RECOMMENDED IF APPLICABLE] 

Use this subelement for chronological subject terms or temporal coverage. It may be 
expressed as a controlled subject term or as a structured date using the same data 
definition as MODS dates. 

If a controlled subject term is used, indicate authority using the authority attribute at 
the <subject> level. Normalized dates are critical for effective searching. Dates should 
be formatted consistently, following the structure dictated by the formatting source used. 
Indicate this source using the encoding attribute. Note that the point attribute is used to 
indicate a date range, not a single date. 

Attributes of <temporal> 

encoding [RECOMMENDED] 

If a structured date is used, indicate the formatting source using the encoding 
attribute. These guidelines recommend using the following value for the 
encoding attribute: 

■ w3cdtf - used for the ISO 8601 profile to specify YYYY-MM-DD date 
patterns 

point [RECOMMENDED IF APPLICABLE] 

The point attribute can be used to encode date ranges using the following values: 

■ start - used for first date of a range 

■ end - used for the end date of a range 



The concept of an "uncontrolled term" is misleading: ideally, all terms used as subject values should be 
controlled, whether that control comes from a formal classification scheme or from a locally developed 
vocabulary. But we also recognize that if one is converting legacy records, subject values may not be 
controlled. However, the recommended best practice is to pull from controlled schema, or to make the 
locally developed list available. 
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If no point attribute is specified, date is assumed to be a single date. 
keyDate [NOT RECOMMENDED] 

Used to specify a single date which should be used by OAI service providers for 
date indexing, sorting, and display. Only one date element should be specified as 
a key date. These guidelines recommend that the keyDate appear in the 
<origininfo> element (see page 30). 

<titleinfo> [RECOMMENDED IF APPLICABLE] 

Use this subelement to indicate a title used as a subject. Note that titles frequently appear 
with a name (i.e., names of composers included with titles of musical works). 

All subelements and attributes used under the top-level element <titleinfo> may be 
used with this subelement; use the <titleinfo> section of the guidelines for more 
explicit guidance (see page 14). 

These guidelines highly recommend using the authority attribute at this level to 
indicate titles controlled by an authority. 

<name> [RECOMMENDED IF APPLICABLE] 

Use this subelement to indicate a name used as a subject. All subelements and attributes 
used under the top-level element <name> may be used; use the <name> section of the 
guidelines for more explicit guidance (See page 18). 

These guidelines highly recommend using the authority attribute to indicate if a name 
is controlled by a record in an authority file. 

<genre> [OPTIONAL] 

MODS 3.2 added <genre> as a subelement under <subject>, which allows legacy 
complex subjects (for example LC Subject Headings) with a form/genre subelement to be 
more appropriately represented in MODS. These guidelines make use of this subelement 
an option but give strong preference to use of the <genre> element for form/genre terms 
whenever possible (see page 28). 

<hierarchicalGeographic> [RECOMMENDED IF APPLICABLE] 

This subelement includes a hierarchical form of a place name relating to the content of 
the resource that is both readable by humans and parsable by machines. This form can be 
applied to the degree of specificity that is known or relevant and used to generate 
browseable hierarchies even when values are specified to different levels. Explicit 
inclusion of the complete hierarchy is of potential benefit for automated consultation of a 
gazetteer to derive map coordinates or to support a map-based interface for searching by 
country or state. This subelement has no attributes. 

Authority should be specified at the <subject> level. 
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The following subelements are defined for <hierarchlcalGeographlc> : 

<continent> 

<country> 

<province> 

<region> 

<state> 

<territory> 

< count y> 

<city> 

<island> 

<area> 

See the MODS User Guidelines for more information on using these subelements. 
<cartographics> [OPTIONAL] 

This element includes cartographic data indicating spatial coverage. If desired, 
cartographic elements may be bound together with a geographic name (hierarchical or 
otherwise) within a <subject> element. This subelement has no attributes. 

This subelement is not fully developed: specific recommendations for its use are not 
possible at this point. Use established standards in your area to guide use of this 
subelement. 

Subelements for <cartographics> 

The following subelements are defined for <cartographics>: 

<coordinates> 

<scale> 

<projection> 

See the MODS User Guidelines for more information on using these subelements. 

<geogra P hicCode> [RECOMMENDED IF APPLICABLE] 

Use this subelement to indicate a geographic code associated with the content of a 
resource. The DLF guidelines recommends the use of a <geographic> or 
<hierarchicalGeographic> value in addition to <geographicCode> to improve the 
searchability of a record. The geographic code should be from an established encoding 
scheme and indicated in the authority attribute. 

Attributes for <geographicCode> 

authority [REQUIRED] 

The authority attribute is used to specify the source of the controlled geographic 
area code. Values for this attribute are: 

marcgac 

marccountry 

iso3166 
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For those not already using MARC, these guidelines recommend using ±so3l66 
as the authority value for <geograph±cCode>. 

<occupat±on> [OPTIONAL] 

Include this subelement a term that is descriptive of the occupation reflected in the 
contents of the described materials. It is not used to list the occupations of the creators of 
the described materials, unless those occupations are significantly reflected in the 
materials themselves or bear some relationship to the materials. This subelement has no 
attributes; specify authority at the <subject> level. 

EXAMPLES OF <subject> USE 

With parsed and repeated <subject> values, with LCSH specified as the authority at the 
<subject> level 

<subject authority= "lcsh "> 

<topi c>Ra ilroads </t opio 

<geographic>West (U.S. ) </geographic> 

<genre>Maps</genre> 
</subject> 

With <subject> values recorded in a string, with LCSH specified as the authority at the 
<subject> level 

<subject authority= "lcsh "> 

<topic>Railroads — West (U.S. ) — Maps</top±c> 
</subject> 

Topical: With <top±c> values recorded in a string, and AAT specified as the authority at 
the <subject> level 

<subject authority="aat"> 

<t opi c>vandali sm</t opi c> 
</subject> 

Topical: With <top±c> grouped with other <subject> subelements that use same 
authority, with LCSH and local specified separately as authority at the <subject> level 

<subject authority="lcsh"> 

<topic>Funeral rites and ceremonies</topic> 

<geographic>Louisiana</geographic> 

<geographic>New Orl eans</geographic> 
</subject> 

<subject author ity=" local" > 

<topic>Jazz funerals</topic> 
</subject> 

Geographic: With LCSH specified as the authority at the <subject> level 

<subject authority= "lcsh "> 

<geographi oUnited States</geographl c> 
</subject> 
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Geographic: With TGM specified as the authority at the <subject> level 

<subject authority="lctgm"> 

<topi OEdu cational buildings</topic> 

<geographic>Washingt on (D.C. ) </geographi c> 

<temporal>1890-1910</temporal> 
</subject> 

Temporal: With the authority attribute used when expressing <temporal> as a 
chronological subject term 

<subject authority="rvm" lang="fre"> 

<topic>Eglise catholique</topic> 

<t opi c>Hi stoire </t opi c> 

<temporal>20e siecle</temporal> 
</subject> 

Temporal: With the encoding attribute used to indicate a single date in time 
<subject> 

<temporal encoding="w3cdtf">1975-05-15</temporal> 
</subject> 

Temporal: With the encoding and point attributes used to indicate a date range 
<subject> 

<temporal encoding="w3cdtf" point="start ">2001-09-ll</temporal> 
<t emporal encoding= "w3cdt f " point = "end ">2 003-03-1 9</t emporal> 
</subject> 

Title: With name and topical subelement 

<subject authority= "lcsh "> 

<name type= "personal" authority="naf"> 

<namePart>Woolf , Virginia</namePart> 
<namePart type="date">1882-1941</namePart> 

</name> 

<titleInfo> 

<title>Three Guineas</title> 

</titleInfo> 

<topic>Criticism and interpretation</topic> 
</subject> 

Name: With type and authority attributes and topical subelement 

<subject authority="lcsh"> 

<name type= "personal" authority="naf"> 

<namePart>Frankenthaler , Helen</namePart> 

<namePart type="date ">1928-</namePart> 
</name> 

<topi c>Painting — Exhibit ions</topic> 
</subject> 

Genre: 

<subject author ity=" lcsh" > 

<name type= "personal" authority="naf"> 
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<namePart>Edmondston, Catherine Devereux</namePart> 
<namePart type="date"> 1823-1875</namePart> 
</name> 

<genre>Diaries</genre> 
</subject> 

Hierarchical Geographic: With authority attribute 

<subject authority= "tgn "> 

<hierarchicalGeographic> 

<country>United States</country> 
<state>Mississippi</state> 
<county>Harrison</county> 
<ci ty>Bi 1 oxi </ci ty> 
</hierarchicalGeographic> 
</subject> 

Cartographic 

<subject> 

<cart ographics> 

<coordinates>E 72° — E 148°/N 13° — N 18°</coordinates> 
<scale>l :22, 000, 000</scale> 
<projection>Conic proj</projection> 
</cart ographi cs> 
</subject> 

Geographic code: 

<subject authority="lcsh"> 

<geographic>Uni ted States</geographi c> 

<geographicCode authority= "iso31 66">us</geographicCode> 
</subject> 

Occupation: With LCSH listed as authority at the <subject> level 

<subject authority="lcsh"> 

<occupa t i on>Mi grant 1 aborers </occupa tion> 

<topic>School district case files</topic> 
</subject> 

Occupation: With AAT listed as authority at the <subject> level 

<subject authority="aat"> 

<occupation>printmaker</occupation> 
</subject> 

USE BY AGGREGATORS 

Subject matter is a critical piece of information for end users to determine the suitability 
of a resource for informational needs; data providers should assume this field will be 
exposed by aggregators. Care should be taken in situations in which subjects are assigned 
by batch process to ensure that the contents of individual items are represented 
accurately. 
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Although information on subject authorities is provided via the model proposed in these 
guidelines, aggregators should not be expected to perform any normalization, linking or 
other processing (although they are free to do so). The authority information is important, 
however, to communicate to the aggregator the nature of subject analysis that has taken 
place, and to reduce semantic confusion based on local subject lists using the same terms 
as shared authority files. 

MAPPING TO DUBLIN CORE 



Using the basis provided by the MODS to Dublin Core Metadata Element Set Mapping 
Version 3.0 (June 7, 2005), these guidelines suggest the following crosswalks between 
MODS element <subject> and simple Dublin Core elements. 



MODS <subject> subelements 


DC elements 


<topic> 
<name> 
<titleInfo> 
<occupation> 


<dc : subject> 


<geographic> 
<temporal> 

<hierarchicalGeographic> 


<dc : coverage> 


<genre> 


<dc : type> 


<cart ographi cs> 
<geographicCode> 


[no field suggested] 



MODS examples above expressed in Dublin Core: 

<dc ; subject>Railroads</dc : subject> 
<dc : coverage>West (U.S. ) </dc : coverage> 
<dc : type>Maps</ dc : type> 



<dc:subject>Railroads — West (U.S. ) — Maps</dc:subject> 
<dc : subject>vandalism</dc : subject> 

<dc: subject>Funeral rites and ceremonies</dc : subject> 
<dc : coverage>Louisiana</dc : coverage> 
<dc : coverage>New Orleans</dc : coverage> 
<dc : sub ject> Jazz funerals</dc : subject> 

<dc : coverage>United States</dc : coverage> 

<dc:subject>Educational buildings</dc:subject> 
<dc : coverage>Washingt on (D.C. ) </dc : coverage> 
<dc : coverage>l 890-1 91 0</dc : coverage> 

<dc : subject>Eglise catholique</dc : subject> 
<dc : subject>Histoire</dc : subject> 
<dc : coverage>20e siecle</dc : coverage> 

<dc : coverage>1975-05-15</dc : coverage> 

<dc:coverage>2001-09-ll - 2003-03-19</dc: cover age> 
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<dc:subject>Woolf, Virginia, 1882-1941</dc:subject> 

<dc : subject>Three Guineas</dc : subject> 

<dc: subject>Criticism and interpretation</dc:subject> 

<dc: subject>Frankenthaler, Helen, 1928-</dc: subject> 
<dc:subject>Painting — Exhibit ions</dc : subject > 

<dc: subject>Edmondston, Catherine Devereux, 1823- 

1 8 75</dc : subject > 

<dc : type>Diaries</dc : type> 

<dc: coverage>United States</dc: coverage> 
<dc : coverage>Mississippi </dc : cover age> 
<dc : cover age>Harrison</ dc : cover age> 
<dc : coverage>Bi 1 oxi </dc : cover age> 

<dc : subject>Migrant laborers</dc : subject> 

<dc: subject>School district case files</dc:subject> 

<dc : subject>printmaker</dc : subject> 

RELATIONSHIP TO THE DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 



The Subjects/Topics section in the DLF/NSDL Best Practices for Shareable Metadata 
discusses the use of subjects. 37 The "Providing supplemental information to service 
providers" is also relevant. 38 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7SubjectPractices 
http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7DocumentingSource 
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<classification> 



MODS Element 


Attributes 


Subelements 


<classification> 


authority 
edition 


None 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records state that the 
use of the <classification> element is optional. This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

A designation applied to a resource that indicates the subject by applying a formal system 
of coding and organizing resources according to subject areas. 

DISCUSSION OF USE 

These guidelines recommend that <classification> contain only classification 
numbers and call numbers whose authorities are referenced in Source Codes for 
Classification maintained by the Library of Congress. 39 It is left to the institution's 
discretion whether to truncate assigned call numbers to just the formal classification 
segment (for example, QA76.17), or to include the full call number (for example, 
QA76.17 T55). Local classification schemes and identifiers should be included in the 
<identifier> element (see page 72). 

Attributes: 

authority [REQUIRED] 

All occurrences of the MODS <classification> element should contain the attribute 
authority to indicate the name of the classification scheme used in the element. Values 
for this attribute should come from the Library of Congress "Source Codes for 
Classification" referenced above. 

edition [RECOMMENDED IF APPLICABLE] 

This attribute designates the edition of the classification scheme named in the authority 
attribute if said scheme is issued in editions. 

EXAMPLES OF <classification>USE 

classification author ity= "lcc ">TH6493</classification> 
Classification author ity="ddc" edition="ll ">683</classification> 

39 http://www.loc.gov/marc/sourcecode/classification/ 
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classification authority="nlm">QW 161 . 5 . S8</classification> 
<classification author ity=" udc">669 . 183 . 211 . 18</classification> 

USE BY AGGREGATORS 

<classification> is not generally used for searching or browsing by aggregators, but 
may appear in the record display. 

MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommends mapping the <classification> element to <dc:subject>. 

MODS examples above in Dublin Core: 

<dc ; subject>TH6493</dc : subject> 
<dc : subject>683</dc : subject > 
<dc:subject>QW 161 .5.S8</dc:subject> 
<dc: subject>669 .183 .211 .18</dc:subject> 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

Although related to the section, Recording Subjects in OAI Records 40 , classification of 
resources is not directly addressed in the DLF/NSDL Best Practices for Shareable 
Metadata. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7SubjectPractices 
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<relatedltem> 



MODS Element 



Attributes 



Subelements 



<relatedltem> 



type 

xlink :href 
di spl ay Label 



All MODS elements can 
appear as subelements of 
<relatedltem>. 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records recommend 
the use of the <relateditem> element in three cases: 

1. to point to a full metadata record for a related item 

2. to provide contextual information useful for full description of the resource. 

3. to provide additional information about intellectual constituent units of the 
resource being described 

This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

Information that identifies other resources related to the one being described. 
<relateditem> is a container element under which any MODS element may be used as a 
subelement. 

DISCUSSION OF USE 

Although the MODS <relateditem> element allows multiple items to be described in a 
hierarchical fashion within a single MODS record, the guidelines recommend that the use 
of the <relateditem> element be restricted to the three cases described below. Do not 
use multiple nested <relatedltem> elements within a single MODS record to describe an 
entire collection in metadata records shared for aggregation. As stated in the MODS User 
Guidelines, "deep recursion may be counter-productive." 

The core MODS record should describe the resource at the level metadata aggregators 
should return as matches to user queries. Information about the original from which a 
digital surrogate or reproduction was made should be included in the main record. Any 
subelements of the <relateditem> element should describe related material of only 
subsidiary interest, helpful for identifying and completely describing a resource, or 
providing context for the resource which may be useful for retrieval. 

The guidelines recommend the use of the <relatedltem> element in the following three 
cases: 

1 . To link to records for related items, without duplicating the metadata for these 
items as subelements of <relateditem>, using the xlink attribute. Best practices 
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for use of the XLink language are still emerging, but potentially the link could be 
used by aggregators to retrieve or interact with the remote metadata. No 
subelements of <relateditem> should be used in this case. Note that a link to 
give user access to a described related resource would be encoded in 
<relatedlt emxl ocati on><url>. 

2. To provide contextual information about the item being described in relationship 
to other items. Applicable subelements of <relateditem> should be used. Most 
frequently, these subelements are used to describe a host item, series, or other 
version. 

3. To provide information about constituent parts when a physical object being 
described (for example a compact disc) contains multiple intellectual items that 
require description (for example tracks on a compact disc). 

Attributes: 

type [REQUIRED] 

The type attribute describes the relationship between the resource in <relateditem> and 
the resource in the parent MODS record. The guidelines recommend the following values 
for each of the recommended uses of <relateditem>: 

Case 1: Linking 

Use any value listed in these guidelines, as appropriate. 
Case 2: Context 

host - Use this value to describe a host or parent resource, for example a book in 
which an article appears or a collection in which an item belongs 

constituent - Use this value to describe parts of the resource, except 
information that falls within the scope of the MODS <tableOfContents> element. 

series - Use this value to describe a named series of which the resource is a part. 

otherversion - Use this value to describe other versions of the work contained 
in the resource. 

Case 3: Constituent parts 

constituent - Use this value to describe constituent parts of the resource that 
warrant separate description. Do not use if this information is more appropriately 
placed in the MODS <tableOfContents> element. 

xlink-.href [RECOMMENDED IF APPLICABLE] 

Use the xlink: href attribute to link to external resources. These guidelines recommend 
that this attribute, when used, contain the URI of a MODS record or an OAI GetRecord 
request, if available, for a related resource. The 'info' URI scheme supported by the 
Library of Congress can also be used to encode an external link here using an LCCN or 
DOI (see http://www.loc.gov/standards/uri/info.html for more information). These 
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guidelines also recommend that no subelements appear under <relatedltem> when this 
attribute is used. 

displayLabel [OPTIONAL] 

The displayLabel attribute may be used to indicate the preferred labeling when 
displayed by a metadata aggregator. Include the text preferred and capitalization, but do 
not include delimiters such as colons. Metadata aggregators may choose to ignore this 
attribute. 

Subelements: 

All MODS elements may appear as subelements of <relateditem>. Follow these 
guidelines in the use of the subelements. 

EXAMPLES OF <relatedltem> USE 

Case 1: Linking 

<relatedltem displayLabel= "Preceding Title" type="preceding" 
xlink:href="http://hdl . loc.gov/umich.dli.moa/AGE3371 "/> 

<relatedltem xlink:href=" info :lccn/ 85000002" /> 

Case 2: Context 

<relatedltem displayLabel= "Appears in" type="host"> 
<titleInfo> 

<title>Post -Fordi sm</t itle> 

<subTitle>A Reader</subTitle> 
</titleInfo> 
<name type= "personal "> 

<namePart type= "given ">Ash</namePart> 

<namePart type= "family ">Amin</namePart> 

<role> 

<roleTerm type="text ">editor</roleTerm> 

</role> 
</name> 
<originInfo> 

<datelssued>1994</datelssued> 

<publ i sher>Blackwel 1 Publ ishers </publ isher> 

<place> 

<placeTerm type="text ">Oxford</placeTerm> 
</place> 
</originInfo> 
<part> 

<extent unit="page "> 

<start>23</start> 
<end>45</end> 
</ extent > 
</part> 
</rel at edit em> 
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Case 3: Constituent parts 

Example of a single track in a MODS record for a compact disc. 

<relatedltem type=" constituent" ID="DMD_disc01_tr001"> 
<titleInfo type="uniform" authority="naf"> 

<title>Chaconne von Vitali</title> 
</titleInfo> 
<titleInfo> 

<title>Chaconne</title> 
</titleInfo> 

<name type= "personal" authority="naf"> 

<namePart>Vitali , Tomaso Antonio</namePart> 
<namePart type= "date ">1 663-1 745</namePart> 
<role> 

<roleTerm authority= "marcrelator " 
type= "text ">composer</roleTerm> 
</role> 
</name> 

<name type= "personal" authority="naf"> 
<namePart>Blatt, Josef </namePart> 
<role> 

<roleTerm authority= "marcrelator " 
type= "text ">performer</roleTerm> 
</role> 
</name> 

<physicalDescription> 

<extent>9 : 55</extent> 
</physicalDescription> 

<note type=" Standard Restriction ">This item is unavailable due to 
copyright restrictions . </note> 

<note type= "per formers ">Nathan Milstein, violin ; Josef Blatt, 
piano. </note> 

<note type=" statement of responsibility" >Tomaso Vitali</note> 
<note>Originally for violin and continuo; arr . for violin and 
piano . </note> 

<note>Attributed to Tomaso Vitali, but most likely not by 
him. </note> 

<subject authority= "lcsh "> 

<topic>Chaconnes (Violin and piano) , Arranged. </topic> 
</subject> 
</relatedItem> 

USE BY AGGREGATORS 

Links to related items may be displayed as links in record displays. Some related item 
elements for some types of relationships may be indexed (for example, series 
<titleinfo> might be indexed as a title or as a series title), and included in record 
display. Some elements of constituent parts may be indexed and included in record 
display. 

MAPPING TO DUBLIN CORE 
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The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommends mapping the contents of the <relateditem> element to the <dc : relation> 
element in simple Dublin Core. However, caution in mapping is recommended because 
<relateditem> elements with many subelements may yield "an incomprehensible 
value." At the very least, mapping multiple subelements to the single <dc : relat±on> 
element will require addition of punctuation and re-ordering of elements to achieve the 
desired result. These guidelines suggest that the type attribute of the <relateditem> 
element may be used to determine a specialized mapping for each type. 

MODS examples above in Dublin Core: 

<dc ; relation>http : //hdl .loc. gov/umich . dli . moa/AGE33 71 
</dc: relation> 

<dc : relation>Amin, Ash, editor. Post-Fordism: A Reader. Oxford: 
Blackwell Publishers, 1994: 23-45 . </dc : relation> 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

The "Describing Versions and Reproductions" 41 and "Bibliographic Citation" 42 pages in 
the DLF/NSDL Best Practices for Shareable Metadata address issues raised by the 
MODS <relateditem> element. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7DigitalTactileResource 
http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7BibliographicCitation 
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<identifier> 



MODS Element 


Attributes 


Subelements 




type 




<i den tifi er> 


invalid 


none 




di spl ayLabel 





SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable Metadata Records 
recommend the use of at least one <identifier> element with the type attribute 
containing appropriate values in each MODS record. This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

A unique standard number or code that distinctively identifies a resource. 
DISCUSSION OF USE 

The <identifier> element is recommended in these guidelines and refers to the digital 
resource being described or to its analog equivalent. In the shared metadata context, the 
<identifier> should identify the object universally; local call numbers or other 
identifiers, therefore, are not generally suitable. However, if a local identifier is used, it 
should be indicated as such using the type attribute. <identifier> has no subelements, 
but does require the type attribute. Repeat this element as required. 

The guidelines recommend that <identifier> be used to encode any identifying 
character string uniquely associated with a resource, but reserves <location><url> for 
encoding the URL to the resource in its repository context. Persistent URIs that serve 
both as a unique identifier and a URL to the resource in its repository context should be 
encoded using both elements. 

These guidelines require that all <identifier> URLs follow the URI specifications laid out 
in the DLF/NSDL Best Practices for Shareable Metadata Content. 43 

Attributes: 

type [REQUIRED] 

All occurrences of the <identifier> element must contain the type attribute to indicate 
the type of the identifier. If a local identifier is used, it should be indicated as such using 
the local value. Following is a list of some of the suggested values for <identifier>, 
but this is not a controlled list. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7IdentifyingTheResource 
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Values for digital object: 

ark (Archival Resource Key) 
doi (Digital Resources Identifier) 
hdl (Handle) 

uri (Uniform Resource Identifier) 

Values for analog original: 

isbn (International Standard Book Number) 

ismn (International Standard Music Number) 

isrc (International Standard Recording Code) 

issn (International Standard Serials Number) 
issue number 

istc (International Standard Text Code) 

lccn (Library of Congress Control Number) 
matrix number 
music plate 
music publisher 

sici (Serial Item and Contribution Identifier) 
stock number 

upc (Universal Product Code) 
invalid [RECOMMENDED IF APPLICABLE] 

This attribute should be used only to signify a canceled or invalid identifier. If used, its 
value must be yes (invalid="yes"). 

displayLabel [OPTIONAL] 

The displayLabel attribute may be used to indicate the preferred labeling when 
displayed by a metadata aggregator. Include the text preferred and capitalization, but do 
not include delimiters such as colons. Metadata aggregators may choose to ignore this 
attribute. 

EXAMPLES OF <identifier> USE 

Encoding a link to a Web page: 
<identifier 

type= "uri "> http : //hemi . es . its .nyu. edu/journal/2_l/ramalho_por.html </ide 
ntifier> 

Encoding an obsolete link to the same Web page: 
<identifier type="uri" 

invalid= "yes " > http : / /hemi . tsoa.nyu. edu/journal/2_l/ramalho__por.html </id 
entifier> 

Other examples: 

<identifier type="lccn ">00694010</identifier> 
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<±dentifier type= "hdl ">hdl : loc. mbrsmi/animp . 4068</identifier> 

USE BY AGGREGATORS 

<±dentif±er> is displayed in some aggregators but is generally not used for retrieval. It 
may in the future be used to de-duplicate aggregations. 

MAPPING TO DUBLIN CORE 

The MODS <identifier> element, along with the <location><URL> subelement, are 
both mapped to <dc : identifier in the MODS to Dublin Core Metadata Element Set 
Mapping Version 3.0 (June 7, 2005). 

MODS examples above expressed in Dublin Core: 

<dc: i den tifi er> http : //hemi . es . its . nyu . edu/journal/2_l/ramalho_por 
. html </dc : i den tifi er> 

<dc:identifier>00694010</dc:identifier> 

<dc : identifier>hdl : loc . mbrsmi/animp . 4068</dc : identifier> 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

Identifier is addressed in the "Recommendations for classes of data elements" under 
"Identifiers." 44 These guidelines recommend the use of the type attribute in lieu of 
prefixing identifiers, as recommended in NSDL/DLF Best Practices for Shareable 
Metadata. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7IdentifvingTheResource 
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<location> 



MODS Element 



Attributes 



Subelements 



displayLabel - 



<physicalLocation> 
authority - 



<location> 



<physicalLocation> 
access - <url> 
usage - <url> 
note - <url> 
displayLabel - <url> 
dateLastAccessed - 



<physicalLocation> 
<url> 



<url> 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require the 
use of at least one <location> element with at least one <url> subelement. One and 
only one <iocation><url> subelement is required to have the usage attribute value 
"primary display". This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

"location" identifies the institution or repository holding the resource, or a remote 
location in the form of a URL where it is available. 

DISCUSSION OF USE 

Use of at least one <location> element with the subelement <url> is required by these 
guidelines. It is required that one and only one <location><url> must include the 
usage attribute value "primary display". Many aggregators may include only one 
URL in their brief display. Use of usage="primary display" allows aggregators to 
easily identify which URL to display for their users. If a record describes multiple items 
(a multi- volume set, for example), these guidelines strongly recommend identifying a 
primary entry point for these. 

These guidelines also recommend that the "access " attribute with the appropriate value 
also be used. Best practice is that the "primary display" URL is a link to the resource 
with its contextual material (for example metadata, navigation to the collection 
homepage). If the primary link to a resource is to a stand alone version of the resource 
(such as a JPEG image only), an end user will have no context except for the metadata on 
the service provider's site. At minimum, the URL should point to a page that contains the 
resource and a navigation bar that allows user to reach the collection homepage. It is 
highly desirable that this page also include the descriptive metadata for the resource. 

In addition, the <location> element with the <url> subelement may be used to encode 
information about the location of other versions, such as a thumbnail, of the digital 
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resource. These guidelines recommend that in these cases the "access " attribute be used 
to identify the version whenever possible. The <locat±on> element with the 
<physlcalLocatlon> subelement may also be used to point to the location of the analog 
resource. However, it is not necessary nor always desirable to include the location of all 
digital and/or analog versions of the described resource. Only include that information 
which is useful and important to the aggregator and to the end user. 

It is recommended that all URLs used with the <locat±on> element be persistent. 

Subelements: 

<physicalLocation> [OPTIONAL] 

Use this subelement to identify the institution or repository holding the resource, or from 
which it is available. Within these guidelines, it identifies the physical, institutional home 
of an analog resource that has been digitized. It is not recommended to include for 
aggregation a physical location for the location of digital files. 

Attributes of <physicalLocation> 

displayLabel [OPTIONAL] 

The displayLabel attribute may be used to indicate the preferred labeling when 
displayed by a metadata aggregator. Include the text preferred and capitalization, 
but do not include delimiters such as colons. Metadata aggregators may choose to 
ignore this attribute. 

authority [RECOMMENDED IF APPLICABLE] 

Use this attribute to indicate the controlled vocabulary used for the value in the 
<physicalLocation> subelement. Permissible values for this attribute are 
marcorg and oclcorg. Use the naming authority appropriate to each value. 45 If 
this attribute is not used, the value is assumed to be a natural language name 
and/or address. In the examples below, the same organization is encoded two 
different ways, the first using the OCLC code for that organization, the second in 
natural language form. 

<url> [REQUIRED] 

Use of at least one <location> element with the subelement <url> with the usage 
attribute value "primary display" is required by these guidelines. This subelement 
contains the Uniform Resource Location (URL) for the resource. The URL provided 
should be persistent. The guidelines recommend that all URLs encoded within the <url> 
subelement should follow the URI specifications laid out in the DLF/NSDL Best 
Practices for Shareable Metadata. 



'See http://www.loc.gov/marc/sourcecode/organization/organizationsource.html. 
'http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7IdentifyingTheResource 
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The <url> subelement may also be used to indicate locations of additional versions of the 
digital resource such as thumbnails. Whenever possible the access attribute should be 
used to help the aggregator determine what versions of the resource are available. 

Attributes of <uri> 

usage [REQUIRED] 

This attribute has one enumerated value: 
primary display 

This attribute must be used with one and only one instance of <location><url>. This 
attribute indicates to the aggregator which URL to include in a short display of a 
metadata record. As stated above, best practice is that the "primary display" URL is a 
link to the resource with its contextual material (for example metadata, navigation to the 
collection homepage). 

access [RECOMMENDED IF APPLICABLE] 

This attribute has three enumerated values: 

preview 
raw object 
object in context 

Use of this attribute is recommended with all instances of <location><url>. This 
attribute helps a metadata aggregator determine what a URL is likely to link to and can 
help determine which URL to use for specific purposes. 

note [OPTIONAL] 

The note attribute may be used to include notes associated with a URL. Use this attribute 
only when other attributes (access, usage, or displayLabel) are not appropriate. 

dateLastAccessed [NOT RECOMMENDED] 

These guidelines do not recommend use of the dateLastAccessed attribute. This 
attribute is unlikely to be useful to an aggregator, and, when persistent URL's are used, 
this attribute will be of little value. 

displayLabel [OPTIONAL] 

The displayLabel attribute may be used to indicate the preferred labeling when 
displayed by a metadata aggregator. Include the text preferred and capitalization, but do 
not include delimiters such as colons. Metadata aggregators may choose to ignore this 
attribute. 

EXAMPLES OF <location> USE 

<location> 
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<url usage= "primary display" access=" object in 

context ">http : //hemi .es.its. nyu . edu/journal/2_l/ramalho_por.html< 

/url> 
</location> 
<location> 

<physicalLocation authority= "oclcorg">NNU</physicalLocation> 
<physicalLocation>New York University, E. H. Bobst Library (New 
York, NY) </physicalLocation> 
</location> 

<location> 

<url usage= "primary display" access=" object in 

context ">http : //webappl . dlib. Indiana . edu/cushman/ results/detail . d 

o?pnum=P04995</url> 

<url access="raw 

object " >http :/ /webappl . dlib. indiana . edu /collect ions /cushman/ 'full/ 
P04995 . jpg</url> 
</location> 

USE BY AGGREGATORS 

Aggregator will use the <location><url us age=" 'primary display"> as the primary 
or - within a short display - the only link for an end user to access the described digital 
resource. Aggregators may choose to display additional <location><url> or 
<locationxphysicalLocation> links to end users, but generally will not use those 
within the search or browse functionality. 

In addition, aggregators may use links provided within <location><url> to collect more 
information for their service. For example, if a URL is provided to image thumbnails 
(access="preview"), an aggregator may spider those URLs to collect the thumbnail. 
These are then displayed with the search results to improve the user's browsing of the 
results. 

MAPPING TO DUBLIN CORE 

<location><url> subelement, along with the <identifier> element, are both mapped 
to <dc : identifier> in MODS to Dublin Core Metadata Element Set Mapping Version 
3.0 (June 7, 2005). The DLF guidelines recommend following this mapping. 

<locationxphysicalLocation> do not easily map to any Dublin Core element; the 
guidelines recommend mapping only the <location><url> if both are available. 

MODS example above expressed in Dublin Core: 

<dc : identifier>http : / /hemi . es . its . nyu . edu/journal/2_l/ramalho__por 
.html </dc : i den tifier> 

<dc : ident if ier>http :/ /webappl . dlib . indiana . edu/cushman/results/de 
tail . do?pnum=P04995</dc : identifier> 

<dc : ident if ier>http :/ /webappl . dlib. indiana. edu/collections/cushma 
n/full/P04995 . jpg</dc : identifier> 
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RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

The <url> subelement of element <locat±on> is addressed in the Recommendations for 
Classes of Data Elements section under "Identifiers" 47 and "Linking from a Record to a 
Resource" 48 under the General Recommendations section. 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7IdentifyingTheResource 
http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7AppropriateLinks 



80 of 117 



DLF/Aquifer Implementation Guidelines for Shareable MODS Records - November 2006 



This page intentionally left blank. 



81 of 117 



DLF/Aquifer Implementation Guidelines for Shareable MODS Records - November 2006 



<accessCondition> 



MODS Element 


Attributes 


Subelements 


<accessCondition> 


type 

di spl ayLabel 


none 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require the 
use of one <accessCondit±on> element with the type attribute containing the value 
useAndReproductlon in every MODS record. This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

Information about restrictions imposed on access to a resource. 
DISCUSSION OF USE 

Use <accessCond±t±on> to indicate rights relating to access and use of digital resources. 

The audience for rights relating to possible uses of digital resources is the end user, so 
rights information should be as free of legalese and technical jargon as possible. State 
clearly any restrictions on use of the digital resource, including explicitly mentioning lack 
of copyright restrictions when the digital resource is in the public domain. Also provide 
contact information for use by end users who wish to pursue required permissions for 
publication, exhibit, or other types of dissemination. If you maintain rights information 
relating to specific digital resources on a web site, you may wish to provide a URL for 
that web site in lieu of a textual rights statement. When doing so, you should provide 
enough textual explanation, along with the URL, to make the purpose of the URL clear to 
end users. 

Whenever possible, consider using a standard license such as Creative Commons and/or a 
rights expression language such as the Open Digital Rights Language (ODRL) 
specification. 

In cases where access to a resource is unrestricted, a statement should appear that says so. 

Attributes: 

type [REQUIRED] 

Use the type attribute to indicate restrictions (or lack thereof) on use of the resource 
and/or restrictions on access to the material. The possible values for this attribute are: 

use and reproduction 
restriction on access 
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At least one occurrence of the <accessCond±t±on> element with a type attribute with 
the value use and reproduction must occur. Use restriction on access only to 
indicate access restrictions (such as those based on institution affiliation or age) rather 
than restrictions on use. Other sorts of restrictions, such as government classification, 
should have no type attribute. 

displayLabel [OPTIONAL] 

The displayLabel attribute may be used to indicate the preferred labeling when 
displayed by a metadata aggregator. Include the text preferred and capitalization, but do 
not include delimiters such as colons. Metadata aggregators may choose to ignore this 
attribute. 

EXAMPLES OF <accessCondition> U SE 

Where use of a resource is restricted: 

<accessCondition type="useAndReproduction">For rights relating to this 
resource, visit http : //hemi . nyu . edu/rights . html</accessCondition> 

<accessCondition type="useAndReproduction">Use of this resource is 
governed by the terms and conditions of the Creative Commons 
"Attribution-NonCommercial-ShareAlike " License 

(http : / / creativecommons . org/licenses/by-nc-sa/2 . 0/) </accessCondition> 

<accessCondition type="useAndReproduction">This video and the 
performance it captures are the sole property of Grupo Cultural 
Yuyachkani . Information regarding syndication and/or replication of 
this work may be obtained by contacting Grupo Cultural Yuyachkani at 
yuyachkani@terra . com.pe </accessCondition> 

Where use of a public-domain resource is unrestricted: 

<accessCondition type="useAndReproduction">Use of this public-domain 
resource is unrestricted. </accessCondition> 

Where a repository wishes to grant unrestricted rights to a resource for which it holds 
copyright: 

<accessCondition type="useAndReproduction">This repository grants to 
all users a free, irrevocable, worldwide, perpetual right of access to, 
and a license to copy, use, distribute, perform and display the 
resource publicly and to make and distribute derivative resources in 
any digital medium for any purpose, as well as the right to make any 
number of copies for any use . </accessCondition> 

Where access to a resource is restricted: 

<accessCondition type="restrictionOnAccess">Restricted: cannot be 
viewed until 2010; Members of donor's family</accessCondition> 
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MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
recommends mapping <accessCondition> to <dc:rights>. 

MODS examples above expressed in Dublin Core: 

<dc: right s>For rights relating to this resource, visit 
http : //hemi . nyu . edu/rights . html</dc : rights> 

<dc: right s>Use of this resource is governed by the terms and 
conditions of the Creative Commons "Attribution-NonCommercial- 
ShareAlike" License (http : / / creativecommons . org /licenses /by-nc- 
sa/2. 0/) </dc: right s> 

<dc: right s>This video and the performance it captures are the 
sole property of Grupo Cultural Yuyachkani . Information regarding 
syndication and/or replication of this work may be obtained by 
contacting Grupo Cultural Yuyachkani at 
yuyachkani@terra . com.pe</dc : right s> 

<dc: right s>Use of this public-domain resource is unrestricted. 
</dc : right s> 

<dc: right s>This repository grants to all users a free, 
irrevocable, worldwide, perpetual right of access to, and a 
license to copy, use, distribute, perform and display the 
resource publicly and to make and distribute derivative resources 
in any digital medium for any purpose, as well as the right to 
make any number of copies for any use. </dc:rights> 

<dc: right s>Restricted: cannot be viewed until 2010; Members of 
don or's fami ly</dc : right s> 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

Access condition is addressed in the "Recommendations for classes of data elements" 
under "Rights for resources". 49 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7RightsPractices 
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<part> 



MODS Element 



Attributes 



Subelements 



type 



<part> 



order 

type - <detail> 
order - <deta±l> 
unit - <extent> 
encoding - <date> 
point - <date> 
qualifier - <date> 



<detail> 
<extent> 
<date> 
<text> 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records recommend 
that the <part> element be used in cases where the part of a resource being represented is 
a physical or structural part of another resource. Examples include an issue of a journal or 
a single story from a collection. This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

The designation of physical parts of a resource in a detailed form. 
DISCUSSION OF USE 

Use <part> when the MODS record in question refers to either a physical or structural 
part of a resource, rather than an intellectual part (which should be recorded in various 
subelements under <title>). A newspaper issue would generally be indicated with 
<part>, rather than indicating the issue number as part of the title in MODS. The <part> 
element at the top level would also be used to describe one reel of microfilm in a set, or 
in any other case in which the part being described is not an intellectual whole by itself. 
When in doubt, and only part numbers or names are needed, use 
<titleInfo><title><partNumber> and/or <titleInfo><title><partName>. 

Attributes: 

type [OPTIONAL] 

A designation of a document segment type. See the MODS User Guidelines for suggested 
values. However, since there is not a controlled set of terms for type, if used, the value 
should be expressed clearly and be generally understandable outside of the local context 
of the resource. 

order [OPTIONAL] 

An integer that designates the sequence of parts. 
Subelements: 
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<detail> [RECOMMENDED IF APPLICABLE] 

Use this subelement to indicate the numbering and type of designation of the part in 
relation to the parent item. 

Attributes of <detaii> 

type [RECOMMENDED IF APPLICABLE] 

Use this attribute to indicate the type of the part described. See the MODS User 
Guidelines for suggested values. However, since there is not a controlled set of 
terms for type, if used, the value should be expressed clearly and be generally 
understandable outside of the local context of the resource. 

order [OPTIONAL] 

Use to describe the level of numbering in the parent item to ensure that the 
numbering is retained in the proper order. 

Subelements of <detaii> 

<number> [OPTIONAL] 

Contains the actual number within the part. 

<ca P tion> [OPTIONAL] 

Contains the caption describing the enumeration within a part. This may be the 
same as type, but conveys what is on the item being described. 

<title> [OPTIONAL] 

Contains the title of the part. Only include if this is different than the title in 
<titleInfo><title>. 

<extent> [RECOMMENDED IF APPLICABLE] 

Use this subelement to indicate the measured units making up the part (for example 
pages, minutes, etc.). 

Attribute of <extent> 

unit [RECOMMENDED IF APPLICABLE] 

Use this attribute to indicate the measure. However, since there is not a controlled 
set of terms for this attribute, the value should be expressed clearly and be 
generally understandable outside of the local context of the resource. 

Subelements of <extent> 

<start> [RECOMMENDED IF APPLICABLE] 
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Use this subelement to indicate the beginning unit of the extent within a part (for 
example, first page). 

<end> [RECOMMENDED IF APPLICABLE] 

Use this subelement to indicate the ending unit of the extent within a part. 
<total> [RECOMMENDED IF APPLICABLE] 

Use this subelement to indicate the total number of units within a part, rather than 
specific units. 

<l±st> [RECOMMENDED IF APPLICABLE] 

Use this subelement to indicate a textual listing of the units within a part (for 
example, "pp. 5-9"). 

<date> [RECOMMENDED IF APPLICABLE] 

Use this subelement for relevant date information. 
Attributes of <date> 
encoding [RECOMMENDED] 

If a structured date is used, indicate the formatting source using the encoding 
attribute. These guidelines recommend using the following value for the 
encoding attribute: 

■ w3cdtf - used for the ISO 8601 profile to specify YYYY-MM-DD date 
patterns 

point [RECOMMENDED IF APPLICABLE] 

The point attribute can be used to encode date ranges using the following values: 

■ start - used for first date of a range 

■ end - used for the end date of a range 

If no point attribute is specified, date is assumed to be a single date. 
qualifier [RECOMMENDED IF APPLICABLE] 

The qualifier attribute has three allowed values: approximate, inferred, and 
questionable. Best practice is to use this attribute with the appropriate value 
when a date is approximate, inferred, or questionable, rather than inserting 
characters such as "ca.", brackets or a question mark within the date string. 

<text> [RECOMMENDED IF APPLICABLE] 
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Use this subelement to record information in textual form. Use this subelement when 
other subelements will not capture the appropriate information. 

EXAMPLES OF <part> USE 

<titleInfo> 

<titl e>Washington observer</t itle> 
</titleInfo> 
<part> 

<detail type= "volume "> 

<number>l</number> 
</detail> 
</part> 

<titleInfo> 

<title>Non-subject-matter Outcomes of Schooling</t±tle> 
</titleInfo> 
<part> 

<detail type= "volume "> 

<number> 9 9</ number > 
</detail> 

<detail type= "issue "> 

<number>5</ number > 
<caption>no . </caption> 
</detail> 

<extent unit="page "> 

<start>131</start> 

<end>l 4 6</end> 
</ extent > 

<date encoding="w3cdtf">1999</date> 
</part> 

USE BY AGGREGATORS 

Aggregators may index <part> with other title information for search purposes; and may 
also include it in a full display. 

MAPPING TO DUBLIN CORE 

The MODS to Dublin Core Metadata Element Set Mapping Version 3.0 (June 7, 2005) 
does not include the <part> element in the mapping to Dublin Core. These guidelines 
recommend adding information appearing at the highest level of the record to title 
information when mapping to simple Dublin Core. 

MODS examples above expressed in Dublin Core: 

<dc : title>Washington observer volume l</dc :title> 

<dc : title>Non-subject-matter Outcomes of Schooling volume, volume 
99, issue 5, page 131-146, 1999</dc:title> 
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RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

The DLF/NSDL Best Practices for Shareable Metadata does not explicitly cover 
description of parts of resources. Some related issues are discussed on the "Granularity of 
Description" page. 50 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7RecordGranularity 
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<extension> 



MODS Element 


Attributes 


Subelements 


<extension> 


none 


none 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records generally 
recommend against the use of the MODS <extens±on> element because any 
subelements within it will likely not be understandable to OAI service providers. 
Exceptions to this recommendation are the use of well-documented community-based 
information for which there is not another appropriate place within the MODS schema. 
An example of this is the use of the "asset action" package. This element is repeatable. 

DEFINITION FROM MODS USER GUIDELINES 

Additional information not covered by MODS. 
DISCUSSION OF USE 

Because no restrictions are imposed on the contents of this element, subelements within it 
will likely not be understandable by OAI service providers. Metadata falling within the 
scope of <extens±on> in a local environment should be included within other MODS 
elements as appropriate or omitted in OAI-harvestable MODS records. 

The exception to this recommendation is the use of well documented community-based 
information for which there is not another appropriate place within the MODS schema. In 
these cases, it is recommended that a schema is used. An example of this is the use of the 
"asset action" package. 51 

EXAMPLES OF <extension> USE 

<extension> 

<location> 

<url access=" asset action package" > 
http://foo.edu/assetactions/999.xml 
</url> 
</location> 
</ext ension> 

USE BY AGGREGATORS 

As noted above, aggregators are not likely to include or use the <extension> element 
unless it is used to contain an agreed-upon set of information in a recognizable schema. 



For more information about "asset actions" see http://www.dlib.org/dlib/october06/cole/10cole.html. 
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MAPPING TO DUBLIN CORE 

Subelements under <extension> are not mapped to Dublin Core in the MODS to Dublin 
Core Metadata Element Set Mapping Version 3.0 (June 7, 2005). 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

The <extens±on> element is not discussed in the DLF/NSDL Best Practices for 
Shareable Metadata. However, the section on "Appropriate Representation of Resources" 
contains some information on what types of information to provide within metadata that 
is being shared via OAI (or by other means). 52 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7AppropriateMetadata 
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<recordlnfo> 



MODS Element Attributes Subelements 



authority - 




<recordCon tent Source> 




encoding - 




<recordCrea t i onDa te> 




and <recordChangeDate> 




point - 




<recordCrea t i onDa te> 


<recordCon tent Source> 


and <recordChangeDate> 


<recordCrea t i onDa te> 


<recordInfo> keyDate 

<recordCrea t i onDa te> 


<recordChangeDate> 


<recordIden tifier> 


and <recordChangeDate> 


<recordOrigin> 


qualifier - 


<languageOfCataloging> 


<recordCrea t i onDa te> 




and <recordChangeDate> 




source - 




<recordIden tifier> 




authority - 




<languageOfCataloging> 




SUMMARY OF REQUIREMENTS 



The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require the 
use of one <recordinfo> element with the subelement <languageOfCataloging> to 
record the language of the text in the MODS record. <recordInfo> is not repeatable. 

DEFINITION FROM MODS USER GUIDELINES 



Information about the metadata record. 
DISCUSSION OF USE 

In general, it is useful for a service provider to have some information about the metadata 
record itself. This type of administrative information can help establish the provenance of 
a metadata record and may enable better interpretation of the content of a metadata 
record. 

<recordinfo> is a wrapper element. It should be used to record information about the 
metadata record that may help a service provider understand or manage the record. 
<recordinfo> may also include information that is relevant only to the creating or 
managing institution; ideally this type of information would not be included in the record 
shared with others. The recommendations for each of the six subelements below make 
specific mention of the types of information useful to service providers. There should be 
only one <recordinfo> element per MODS record. 
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Within the OAI context, information about the metadata record may also be recorded in 
an optional <about> container outside of the <metadata> container. The information 
contained in the MODS <recordinfo> may be repeated in the <about> container for the 
MODS record, but is not required. 

Subelements: 

<recordContentSource> [RECOMMENDED] 

Use <recordContentSource> to indicate the code or name of the organization that either 
created or modified the original record. This information can be useful to trace the 
provenance of a particular metadata record, particularly if the record has been re-exposed 
via an aggregator. The name or code should be pulled from an authoritative list and 
indicated in the authority attribute. 

Attributes of <recordContentSource> 

authority [RECOMMENDED] 

The name of the authoritative list for a controlled value is recorded here. The 
Library of Congress maintains "Organization Source Codes." If the authority 
attribute is not included, the value is presumed to be textual (for example, a name 
of an institution). 

<recordCreationDate> [OPTIONAL] 
<recordChangeDate> [OPTIONAL] 

These subelements are used to record the date the original MODS record was created and 
last modified, respectively. These guidelines make no specific recommendation on their 
use. Within the OAI context, service providers are more likely to rely on the 
<datestamp> within the OAI header for information about when the record was created 
or last modified than these dates. 

If either or both of these subelements is used, follow the guidelines outlined in the date 
section of the <or±g±ninfo> element (see page 30). The one exception is that neither of 
these subelements should be identified as the keyDate. 

Attributes of <recordCreationDate> and <recordChangeDate> : 

encoding [OPTIONAL] 

If a structured date is used, indicate the formatting source using the encoding 
attribute. These guidelines recommend using the following value for the 
encoding attribute: 

■ w3cdtf - used for the ISO 8601 profile to specify YYYY-MM-DD date 
patterns 

point [OPTIONAL] 

53 http://www.loc.gov/marc/sourcecode/organization/organizationsource.html 
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The point attribute can be used to encode date ranges using the following values: 

■ start - used for first date of a range 

■ end - used for the end date of a range 

If no point attribute is specified, date is assumed to be a single date. 
keyDate [NOT RECOMMENDED] 

Used to specify a single date which should be used by OAI service providers for 
date indexing, sorting, and display. Only one date element should be specified as 
a key date. These guidelines recommend that the keyDate appear in the 
<origininfo> element (see page 30). 

qualifier [NOT RECOMMENDED] 

The use of the qualifier attribute within date information in <recordInfo> is not 
recommended. If the creation or change date is not known or must be inferred, it 
is probably not useful to include. 

<recordIdentifier> [OPTIONAL] 

Use this subelement to record the system control number assigned by the organization 
creating, using, or distributing the record. These guidelines make no specific 
recommendation on its use. Within the OAI context, service providers are likely to rely 
on the <identifier> in the OAI header, rather than the <recordidentifier>. If 
<recordidentifier> is used, the guidelines recommend the use of the source attribute 
if possible. 

Attributes of <recordIdentifier> 

source [RECOMMENDED] 

This attribute contains the code or name of the organization whose system control 
number is located in the <recordidentifier> element. The source name should 
be from a controlled list 54 if possible, although there is not a way to indicate the 
controlled list. 

<recordOrigin> [RECOMMENDED] 

Use this subelement to record information about the origin, or provenance of the MODS 
record including how it was generated and what transformations have been applied. The 
information here can be useful for a service provider to understand specific encoding 
conventions within element values or why certain types of information appear in certain 
places (for example, if the MODS record was transformed from a MARC record using 
the standard Library of Congress stylesheet). These guidelines recommend using free text 
with the stipulation that values be understandable outside of the local context of the 
creating institution. Institutions may include as much or as little detail as desired in this 



http://www.loc.gov/marc/sourcecode/organization/organizationsource.html 
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element; however, information such as whether a transformation was done by machine or 
by hand, and if a standard set of transformation rules was used are useful to service 
providers. 

<languageOfCataloging> [REQUIRED] 

Use <languageOfCatalog±ng> to record the language of the text of the cataloging in the 
MODS record. These guidelines require the use of this subelement and its subelement 
<languageTerm> to record the primary language of the values found within MODS 
elements. If additional language(s) are used this should be indicated with the lang 
attribute within the specific top-level element(s) in which the additional language(s) 
appears (seepage 100). 

Subelement of <languageOfCataloging> 

<languageTerm> [REQUIRED] 

This subelement contains the language of the text of the cataloging in the MODS 
record. These guidelines require one pair of <languageTerm> elements 
representing the primary language of the text wrapped in a single <language> 
element. One of these <languageTerm> elements should carry the attribute 
type="text " and the other should have type="code". Additional pairs of 
<languageTerm> elements representing secondary languages may be included in 
separate <language> elements. 

Attributes of <languageTerm> 

authority [REQUIRED IF APPLICABLE] 

These guidelines require using the value ±so639-2b for this attribute in 
the <languageTerm> element. 

EXAMPLE OF <recordInfo> USE 

<recordInfo> 

<re cordCon tentSource 

author ity="oclcorg">UIU</recordContentSource> 
<recordOrigin>Record has been transformed into MODS from a 
qualified Dublin Core record using a stylesheet available at 
http://www.sample.edu/. Metadata originally created in a locally 
modified version of qualified Dublin Core (data dictionary 
available : http: //www. sample. edu/ . ) </recordOrigin> 
<languageOfCataloging> 

<languageTerm authority= " iso639-2">eng</languageTerm> 
</languageOfCataloging> 
</recordInfo> 

USE BY AGGREGATORS 

The <recordinfo> field contains information that will be of use to aggregators in 
determining how best to understand and process a record for use in the aggregation. None 
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of the fields are likely to be displayed to end users of the aggregation interface, or be 
indexed for end user search. 

MAPPING TO DUBLIN CORE 

These guidelines and the MODS to Dublin Core Metadata Element Set Mapping Version 
3.0 (June 7, 2005) make no recommendations about mapping <recordinfo> to a simple 
Dublin Core element. For the purposes of the required Dublin Core records within the 
OAI context, information contained within a MODS <recordinfo> element could be 
mapped to an OAI <about> container for each OAI Dublin Core record disseminated 
from a MODS item, or, alternatively, this information is documented in a publicly 
accessible place and referenced from the <about> container or the <setDescr±pt±on>. 

However, these guidelines do recommend documenting cataloging decisions in a publicly 
accessible location so that service providers can better interpret metadata records. 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

The DLF/NSDL Best Practices for Shareable Metadata discuss issues related to 
<recordinfo> in the "Providing Supplemental Documentation to OAI Service 
Providers" section. 55 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7DocumentingSource 
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Attributes Common to Most Elements 



Attributes 

lang 
xml : lang 
script 

transliteration 
ID 

xlink 



SUMMARY OF REQUIREMENTS 

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require the 
use of the lang attribute when a language is used in the value of an element that is not the 
same as that indicated in the <languageOfCataloging> subelement of the 
<recordOrigin> element. The use of the xml -.lang attribute is not recommended. The 
use of the script and transliteration attributes is recommended if applicable. These 
guidelines have no recommendation on the use of the id attribute. The use of the xlink 
attribute is recommended when applicable, particularly within the <relateditem> or 
<tableOfContents> elements. The common attributes for elements relating to dates are 
covered in the applicable sections. 

DEFINITION FROM MODS USER GUIDELINES 

See http://www.loc.gOv/standards/mods/v3/mods-userguide-generalapp.html#list. 

DISCUSSION OF USE 

lang [REQUIRED IF APPLICABLE] 

The lang attribute should be used when a language is used in the value of an element that 
is not the same as that indicated in the <languageOfCataloging> subelement of the 
<recordOrigin> element. The value for the attribute must be taken from ISO 639-2/b. 56 

xml :lang [NOT RECOMMENDED] 

The use of the xml -.lang attribute is not recommended. 

script [RECOMMENDED IF APPLICABLE] 
transliteration [RECOMMENDED IF APPLICABLE] 

Use of the script and transliteration attributes is recommended if applicable. Note 
that there is no standard list of transliteration schemes available; the value of this attribute 
may be limited until one is developed. 



http://www.loc.gov/standards/iso639-2/ 
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id [OPTIONAL] 

The use of the id attribute is optional. 

xlink [RECOMMENDED IF APPLICABLE] 

Use the xllnk attribute in cases where there is a need to reference an external resource 
such as a second metadata record. See <tableOfContents> (page 46) for examples. 

EXAMPLES OF COMMON ATTRIBUTES 

<abstract>This paper examines the Impact of schooling and income on 
fertility in Cote d'lvoire using data from the 1985 Cote d'lvoire 
Living Standards Survey . </abstract> 

<abstract lang="fre"> Ce document examine 1 'impact de la scolarisation 
et du revenu sur la fecondite en Cote d'lvoire en utilisant les donnees 
de l'Enquete sur les Niveaux de Vie en Cote d'lvoire de 
1985 . </abstract> 
<recordInfo> 

<languageOfCataloging> 

<languageTerm authority= " iso639-2">eng</languageTerm> 

</languageOfCataloging> 
</recordInfo> 

<relatedltem displayLabel="Preceding Title" type=" preceding" 
xlink:href="http://hdl . loc.gov/umich.dli.moa/AGE3371 "/> 

<t abl eOfCon tents 

xlink :href="http : //www. ojp . usdoj . gov/bjs/toc/cchrie98 . htm" /> 

USE BY AGGREGATORS 

Use of the common attributes will depend upon the individual aggregator. In the case of 
the xlink attribute, for example, aggregators may provide the link to the end user. 

MAPPING TO DUBLIN CORE 

These guidelines and the MODS to Dublin Core Metadata Element Set Mapping Version 
3.0 (June 7, 2005) make no recommendations about mapping the common attributes to 
simple Dublin Core elements. 

RELATIONSHIP TO DLF/NSDL BEST PRACTICES FOR 
SHAREABLE METADATA 

None of the common attributes are specifically discussed in the DLF/NSDL Best 
Practices for Shareable Metadata. However, the general issues around documenting how 
metadata values are recorded are discussed in the Providing Supplemental Information to 
a Service Provider section. 57 



http://oai-best.comm.nsdl.org/cgi-bin/wiki.pl7DocumentingSource 
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Full MODS Examples Encoded to These Guidelines 



NOTE ON THESE EXAMPLES 

Source records for these examples were borrowed with permission from Indiana 
University Bloomington, the Library of Congress, the University of Illinois at Urbana- 
Champaign, and Emory University. Some content and encoding in the examples has been 
altered from the original to insure that they adhere to the recommendations in these 
guidelines. The examples are illustrative, not prescriptive, and their inclusion is intended 
only to assist in understanding how these guidelines might be applied. 

Examples are supplied for the following types of materials: 

1. book (page 102) 

2. film (page 104) 

3. map (page 106) 

4. photograph (page 108 

5. print (page 110) 

6. sheet music (page 112) 

7. physical artifact (page 114) 

8. born digital item (page 115) 



Example 1: Record for a book (Library of Congress) 

<mods xmlns= "http : //www. loc . gov/mods/v3 " 
xmlns :xsi= "http: //www. w3 . org/2001 /XMLSchema-instance " 
xsi : schemaLocation= "http : //www. loc . gov/mods/v3 
http: //www. loc.gov/standards/mods/v3/mods-3-2 .xsd"> 
<titleInfo> 

<title>Letters of a volunteer In the Spanish-American war</title> 
</titleInfo> 

<name type= "personal" author ity="naf"> 

<namePart>King, George G. (George Glenn) </namePart> 
<role> 

<roleTerm author ity= "marcrelator " 
type= "text ">creator</roleTerm> 
</role> 
</name> 

<typeOfResource>text</typeOfResource> 
<genre authority=" aat " ' >monographs</genre> 
<genre authority=" aat ">correspondence</genre> 
<originInfo> 
<place> 

<placeTerm type="code " author ity= "marccountry " >ilu</placeTerm> 

<placeTerm type="text ">Illinois</placeTerm> 
</place> 
<place> 

<placeTerm type="text ">Chicago</placeTerm> 
</place> 

<publisher>Hawkins and Loomis</publisher> 

<datelssued encoding="w3cdtf" keyDate="yes">1929</dateIssued> 
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</ originInfo> 
<language> 

<languageTerm type="text ">English</languageTerm> 

<languageTerm type="code" authority="iso639- 

2b ">eng</languageTerm> 
</language> 
<physicalDescription> 

<extent> 3 p.l., 5-133 p. 23 cm. </extent> 

<note>All pages of the original have been digitized. </note> 
<internetMediaType>text/html</internetMediaType> 
<internetMediaType>image/jpeg</internetttediaType> 
<internetMediaType>image/tiff</internetMediaType> 
<digitalOrigin>re formatted digital</digitalOrigin> 
</physicalDescription> 

<abstract>This book is a collection of letters written home by 
George King, an American soldier who served in the Puerto Rican 
campaign during the Spanish-American War. At the outbreak of the 
War, King volunteered in the Sixth Regiment of Infantry formed in 
Concord, Massachusetts. He rose quickly to the rank of sergeant. 
King describes in some detail the life of a soldier during the war, 
including the kind and extent of training received, and the lean 
diet and physical hardships of campaigning in Puerto Rico. King's 
letters are interspersed with notes and explanatory commentary that 
puts his letters in perspective . Some of his letters and 
commentaries describe the interrelationships between American 
soldiers and the inhabitants of Puerto Rico during the War. He 
pointed out, for example, that the Americans hired native Puerto 
Ricans, who rendered the army efficient and valuable service as 
mounted scouts . </abstract> 
<subject authority= "lcsh "> 

<geographic> United States</geographic> 

<geographicCode authority= "marcgac ">n-us </geographicCode> 

</subject> 

<subject authority= "lcsh "> 

<topic>Spanish-American War, 1898</topic> 

<t opi c>Personal narrati ves</t opi c> 
</subject> 

<identifier type="lccn ">30012858</identifier> 

<identifier type="hdl ">hdl : loc . gdc/lhbpr . 12858</identifier> 

<location> 

<url usage= "primary display" access=" object in 
context ">http: //hdl . loc.gov/loc.gdc/lhbpr. 12858</url> 
</location> 

<accessCondition type="useAndReproduction">The Library of Congress 
is providing access to these materials for educational and research 
purposes. The written permission of the copyright owners and other 
rights holders (such as holders of publicity and /or privacy rights) 
is required for distribution, reproduction, or other use beyond that 
allowed by fair use or other statutory exemptions . Note that there 
may be U.S. copyright protection (see Title 17, U.S.C.) or other 
restrictions in these materials. However, the Library is not aware 
of any copyrights or other rights associated with this 
material . </accessCondition> 
<recordInfo> 

<recordCon tentSource 

author ity="marcorg ">DLC</recordContentSource> 
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<recordCreationDate encoding="w3cdtf ">1 982-11- 
08</recordCreationDate> 

<recordChangeDate encoding="w3cdtf">2002-03-20</recordChangeDate> 
<recordIdentifier source="DLC">30012858</recordIdentifier> 
<recordOrigin>Derived from a MARC record using the Library of 
Con gress stylesheet </recordOri gin> 
<languageOfCataloging> 

<languageTerm authority= "iso639-2b ">eng</languageTerm> 
</languageOfCataloging> 
</recordInfo> 
</mods> 

Example 2: Record for a film (Library of Congress) 

<mods xmlns= "http : //www. loc . gov/mods/v3 " 
xmlns :xsi= "http: //www. w3 . org/2 0 0 1 /XMLSchema-instance " 
xsi : schemaLocation= "http : //www. loc . gov/mods/v3 
http: //www. loc.gov/standards/mods/-v3/mods-3-2 .xsd"> 

<titleInfo> 

<title>Dud leaves home</title> 

</titleInfo> 

<titleInfo type=" alternative" displayLabel= "Variant title in Library 
of Congress video collection"> 

<title>Us fellers: "Dud leaves home"</title> 
</titleInfo> 

<titleInfo type=" alternative" displayLabel="Copyright title"> 

<title>Goldwyn-Bray Pictographs, no. 7009</title> 
</titleInfo> 

<name type= "personal" authority="naf"> 
<namePart>Carlson, Wallace</namePart> 
<namePart type="date">d. 1967</namePart> 
<role> 

<roleTerm author ity= "marcrelator " 

type= "text ">animator</roleTerm> 
</role> 
<role> 

<roleTerm author ity= "marcrelator " 
type= "text ">scenarist</roleTerm> 
</role> 
</name> 

<name type=" corporate" author ity="naf"> 

<namePart>Bray Pictures Corporation</namePart> 
</name> 

<typeOfResource>moving image</typeOfResource> 
<genre author ity=" mar c">mot ion picture</genre> 
<genre author i ty= "mi gfg ">Comedy-Animati on-Short </genre> 
<originInfo> 
<place> 

<placeTerm type="code " authority= "marccountry " >xxu</placeTerm> 
<placeTerm type="text">United States</placeTerm> 
</place> 

<publisher>Bray Pictures Corp . </publisher> 

<datelssued encoding="w3cdtf" keyDate="yes" 

qualifier=" inferred" >1 91 9</dateIssued> 
</ originInfo> 
<language> 
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<languageTerm type="text ">English</languageTerm> 

<languageTerm authority= "iso639-2b " 

type= "code ">eng</languageTerm> 
</language> 
<physicalDescription> 

<extent>l reel of 1 (ca. 170 ft.) : si., b and w ; 16 mm. ref 

print . </extent> 

<extent>Duration: 4:57 at 22 fps . </extent> 

<note> The entire content of the original has been 

digitized. </note> 

<internetMediaType>video/mpeg</ internetMediaType> 
<internetMediaType>video/quicktime</ ' internetMediaType> 
<digitalOrigin>re formatted digital</digitalOrigin> 
</physicalDescription> 

<abstract>Dud wants to buy his girlfriend Maime an ice cream cone so 
he breaks open his mother's bank, and splits their last dime in half 
in the process . His mother punishes him so he runs away. Dud is 
scared by imaginary ghosts in the dark, so he runs back home where 
he gets a spanking from his mother . </abstract> 

<note displayLabel=" Statement of responsibility" >Bray Pictures 
Corporation ; animator and writer, Wallace Carlson . </note> 
<note>Digital file includes a piano score composed and performed by 
Philip Carli . </note> 
<subject authority= "lcsh "> 
<t opi OBoys </topic> 

<geographic>United States</geographi c> 
<genre>Drama </ genre> 
</subject> 

<subject authority= "lcsh "> 

<topic>Runaway teenager s</topic> 

<geographi oUnited States</geographi c> 

<genre>Drama </ genre> 
</subject> 

<subject authority= "lcsh "> 

<topic>Mothers and sons</topic> 

<geographi oUnited States</geographi c> 

<genre>Drama </ genre> 
</subject> 

<subject authority= "lcsh "> 

<t opi c>St ealing</t opi c> 

<geographi oUnited States</geographi c> 

<genre>Drama </ genre> 
</subject> 

<subject authority= "lcsh "> 

<topic>Discipline of children</topic> 

<geographi oUnited States</geographi o 

<genre>Drama </ genre> 
</subject> 

<subject authority= "lcsh "> 

<t opi oPuni shmen t </t opio 

<genre>Drama </genre> 
</subject> 

<subject authority= "lcsh "> 

<t opi oGhosts </t opi c> 

<genre>Drama</genre> 
</subject> 

<relatedltem type="host" displayLabel="Part of"> 
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<titleInfo> 

<t it le>AFI /Marshall (George) Collection (Library of 
Congress) </title> 
</titleInfo> 
</rel at edit em> 
<relatedltem type= "series "> 
<titleInfo> 

<title>Us fellers</title> 
</titleInfo> 
</rel at edit em> 
<relatedltem type= "series "> 
<titleInfo> 

<title>Gol dwyn -Bray pict ographs</t itle> 
</titleInfo> 
</relatedItem> 

<identifier type="lccn ">00694010</identifier> 

<identifier type= "hdl ">hdl :loc. mbrsmi/animp . 4068</identifier> 
<location> 

<url usage= "primary display" access=" object in 
context ">http : //hdl . loc. gov/loc . mbrsmi/animp . 4068</url> 
</location> 

<accessCondition type="useAndReproduction">For information on rights 
relating to this resource, visit 

http: //www. loc.gov/homepage/legal . html#copyright</accessCondition> 
<recordInfo> 

<recordCon tentSource 

author ity= "marcorg ">DLC</recordContentSource> 
<recordCreationDate encoding="w3cdtf ">1 999-12- 
0 1 </re cordCrea t i onDa te> 

<recordChangeDate encoding="w3cdtf">2000-12-19</recordChangeDate> 
<recordIdentifier source="DLC">00694010</recordIdentifier> 
<recordOrigin>Sources used: Copyright catalog, motion pictures, 
1912-1939; Library of Congress video collection, v. 3, Origins of 
American animation, 1900-1921; Mclntire, J. Silent animated films 
at the Library of Congress, 1995; M/B/RS shelf list . Summary from 
J. Mclntire, Silent animated films at the Library of Congress, 
1995 . </recordOrigin> 
<languageOfCataloging> 

<languageTerm authority= "iso639-2b ">eng</languageTerm> 
</languageOfCataloging> 
</recordInfo> 
</mods> 

Example 3: Record for a map (Library of Congress) 

<mods xmlns= "http: //www. loc. gov/mods/v3" 
xmlns :xsi= "http: //www. w3 . org/2001 /XMLSchema-instance " 
xsi : schemaLocation= "http : //www. loc . gov/mods/v3 
http: //www. loc.gov/standards/mods/v3/mods-3-2 .xsd"> 
<titleInfo> 

<t it le>D alias , Texas. With the projected river and navigation 
improvements viewed from above the sister city of Oak 
Cliff</title> 
</titleInfo> 

<name type= "personal" author ity="naf"> 

<namePart type= "family ">Giroud</namePart> 
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<namePart type= "given " >Paul</namePart> 
<role> 

<rol e Term author i ty= "mar ere lator" 
type= "text ">cartographer</roleTerm> 
<rol e Term author i ty= "mar ere lator" 
type= "code ">ctg</roleTerm> 
</role> 
</name> 

<typeOfResource>cartographic</typeOfResource> 
<genre author ity=" 'let gm" >panoramic views </genre> 
<originInfo> 
<place> 

<placeTerm type="text ">Dallas?</placeTerm> 
</place> 

<publisher>Dallas Lith. Co . </publisher> 

<datelssued encoding="w3cdtf" 

keyDate= "yes ">1892</datelssued> 
</originInfo> 
<language> 

<languageTerm type="text ">English</languageTerm> 
<languageTerm type="code" authority="iso639- 
2b ">eng</languageTerm> 
</language> 
<physicalDescription> 

<extent>col . map 26 x 53 cm. on sheet 53 x 75 cm. </extent> 
<internetMediaType>image/tiff</internetMediaType> 
<digitalOrigin>re formatted digital</digitalOrigin> 
</physicalDescription> 

<note>Perspective map not drawn to scale . </note> 
<note>Bird ' s-eye-view. </note> 

<note>Includes illus. and advertisements . </note> 
<subject authority="lcsh"> 

<geographic>Dallas (Tex.) </geographic> 

<genre>Aerial views</genre> 
</subject> 

<subject author ity="tgn"> 
<hierarchicalGeographic> 

<country>United States</country> 
<state>Texas</state> 
<city>Dallas</city> 
</hierarchicalGeographic> 
</subject> 

<identifier type="hdl"> 

http: //hdl . Ioc.gov/loc.gmd/g4034d.pm009070 </identifier> 
<location> 

<url usage= "primary display" access=" object in 

context ">http: //hdl . loc.gov/loc. gmd/g4034d.pm009070</url> 

</location> 

<location> 

<physicalLocation> Library of Congress Geography and Map 
Division Washington, D.C. 20540-4650 USA </physicalLocation> 
</location> 

<accessCondition type="useAndReproduction">Most maps in the Map 
Collections materials were either published prior to 1922, 
produced by the United States government, or both (see catalogue 
records that accompany each map for information regarding date of 
publication and source) . A few have permission from the copyright 
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holders as noted in the descriptive record. The Library of 
Congress is providing access to these materials for educational 
and research purposes and is not aware of any U.S. copyright 
protection (see Title 17 of the United States Code) or any other 
restrictions in the Map Collection materials. Note that the 
written permission of the copyright owners and/or other rights 
holders (such as publicity and/or privacy rights) is required for 
distribution, reproduction, or other use of protected items 
beyond that allowed by fair use or other statutory exemptions . 
Responsibility for making an independent legal assessment of an 
item and securing any necessary permissions ultimately rests with 
persons desiring to use the item. </accessCondition> 
<recordInfo> 

<recordCon tentSource 

authority= "marcorg ">MdBJ</recordContentSource> 
<recordCreationDate encoding="w3cdtf">2005-10- 
28</recordCreationDate> 

<recordOrigin>Base MODS record derived from Library of 
Congress American Memory Project record, then edited to 
conform to the DLF Implementation Guidelines for Shareable 
MODS Records . </recordOrigin> 
<languageOfCataloging> 

<languageTerm authority= "iso639-2b ">eng</languageTerm> 
</languageOfCataloging> 
</recordInfo> 
</mods> 

Example 4: Record for a photograph (Library of Congress) 

<mods xmlns= "http : //www. loc . gov/mods/v3 " 
xmlns : xsi="http : //www . w3 . org / '2001 /XMLSchema-instance " 
xsi : schemaLocation= "http : //www. loc . gov/mods/v3 
http: //www. loc. gov/ standards /mods /v3/mods-3-2.xsd"> 
<titleInfo> 

<title>General view of Balaklava, the hospital on the 
right</title> 
</titleInfo> 

<name type= "personal" authority="naf"> 
<namePart>Fenton, Roger </namePart> 
<namePart type="date ">1819-1869</namePart> 
<role> 

<roleTerm author ity= "marcrelator " 

type= "text ">creator</roleTerm> 
</role> 
<role> 

<roleTerm author ity= "marcrelator " 
type= "text ">photographer</roleTerm> 
</role> 
</name> 

<typeOfResource>sti 1 1 image</typeOfResource> 

<genre authority="gmgpc">Salted paper prints-1850-1860 . </genre> 
<originInfo> 
<place> 

<placeTerm type="code " authority= "marccountry " >enk</placeTerm> 
<placeTerm type="text " >England</placeTerm> 
</place> 
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<datelssued encoding="w3cdtf" keyDate="yes" 

qualifier=" inferred" >1855</datelssued> 
</originInfo> 
<physicalDescription> 

<extent>l photographic print : salted paper ; 30 x 36 

cm. </extent> 

<note>The entire content of the original has been 
digitized. </note> 

<internetMediaType>image/ jpeg</ internetMediaType> 
<internetMediaType>image/tiff</internetMediaType> 
<digitalOrigin>re formatted digital</digitalOrigin> 
</physicalDescription> 

<abstract>Includes buildings in the foreground, a view of the 
harbor, and military tents scattered on the hills to the left in the 
background. </abstract> 

<note>Title transcribed from verso . </note> 

<note>Roger Fenton, photographer of the Crimean War: His photographs 
and his letters from the Crimea, with an essay on his life and work 
/ Helmut and Alison Gernsheim. London : Seeker and Warburg, 1954, 
no. 21 .</note> 
<subject authority="lcsh"> 

<geographic>Ukraine</geographic> 

<geographicCode authority= "marcgac ">e-un </geographicCode> 

</subject> 

<subject authority="lcsh"> 

<topic>Crimean War, 1853-1 85 6</topic> 
</subject> 

<subject authority="lctgm"> 

<topic>Cities and towns</topic> 

<geographic>Ukraine</geographic> 

<geographic>Balaklava</geographic> 

<temporal>1850-1860</temporal> 
</subject> 
<subject> 

<geographic>Balaklava (Ukraine) </geographic> 
<temporal>1850-1860</temporal> 
</subject> 

<classification author ity="lcc">PH - Fenton (R.), no. 
81</ classification 
<relatedltem type="host"> 
<titleInfo> 

<title>Roger Fenton Crimean War photograph collect ion</t it le> 
</titleInfo> 
<name> 

<namePart>Fenton, Roger, 1819-1869 . </namePart> 
</name> 

<i den tifier type= "lccn">2001 696100 </i den tifier> 
<note>Purchase; Frances M. Fenton; 1944.</note> 
<accessCondition type= "restrict ionOnAccess ">Restricted access : 
Materials extremely fragile; Served by appointment 
only. </accessCondition> 
</relatedItem> 

<identifier type= "lccn ">2001 698800</identifier> 
<identifier type=" stock number ">LC-USZC4-91 98 DLC</identifier> 
<identifier type="stock number" >LC-USZ62-2370 DLC</identifier> 
<identifier type="hdl" displayLabel=" color film copy 
transparency" >hdl : loc .pnp/cph . 3g09198</identifier> 
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<identifier type="hdl" displayLabel="b and w film copy 
neg. ">hdl : loc . pnp/cph . 3a06070</identifier> 
<location> 

<url usage= "primary display" access="object in 
context ">http: //hdl . loc . gov/loc .pnp/cph . 3g09198</url> 

</location> 

<location> 

<physicalLocation>Library of Congress Prints and Photographs 
Division Washington, D.C. 20540 USA</physicalLocation> 
</location> 

<accessCondition type="useAndReproduction">No known restrictions on 

publication. </accessCondition> 

<recordInfo> 

<recordCon tentSource 

author ity= "marcorg ">DLC</recordContentSource> 
<recordCreationDate encoding="w3cdtf">2001-07- 
25</re cordCrea t i onDa te> 

<recordChangeDate encoding="w3cdtf">2002-ll-ll</recordChangeDate> 
<recordIdentifier source="DLC">2001698800</recordIdentifier> 
<recordOrigin>Derived from a MARC record using the Library of 
Congress stylesheet then edited to conform to the DLF 
Implementation Guidelines for Shareable MODS 
Records . </recordOrigin> 
<languageOfCataloging> 

<languageTerm authority= "iso639-2b ">eng</languageTerm> 
</languageOfCataloging> 
</ recordInfo> 
</mods> 

Example 5: Record for a print (Library of Congress) 

<mods xmlns= "http : //www. loc . gov/mods/v3 " 
xmlns : xsi="http : //www . w3 . org/2 0 0 1 /XMLSchema-instance " 
xsi : schemaLocation= "http : //www. loc . gov/mods/v3 
ht tp : / /www .loc. gov/ standards /mods /v3/mods-3-2 . xsd "> 
<titleInfo> 

<title>Freedom of expression, of religion, from want, from fear 
everywhere in the world</title> 
</titleInfo> 

<name type=" corporate" author ity="naf"> 

<namePart>Federal Art Project</namePart> 
<role> 

<roleTerm author ity= "marcrelator " 
type= "text ">sponsor</roleTerm> 

<roleTerm author ity= "marcrelator" type="code">spn</roleTerm> 
</role> 
</name> 

<typeOfResource>sti 1 1 image</typeOfResource> 
<genre authority= "lctgm">Posters</genre> 
<genre authority="lcsh">Posters — 20th century </genre> 
<genre authority="lctgm">Screen prints — Color — 1 930-1 950</genre> 
<originInfo> 
<place> 

<placeTerm type= "text ">Penn [ sylvania ] </placeTerm> 
</place> 

<publisher>Penna Art WPA</publisher> 
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<datelssued> [between 1936 and 1941] </dateIssued> 
<datelssued encoding="w3cdtf" point="start" keyDate="yes" 
qualifier=" approximate ">1936</datelssued> 

<datelssued encoding="w3cdtf" point="end">1941</dateIssued> 
</originInfo> 
<language> 

<languageTerm type="text ">English</languageTerm> 
<languageTerm type="code" authority="iso639- 
2b ">eng</languageTerm> 

</language> 

<physicalDescription> 

<internetMediaType>image/tiff</internetMediaType> 

<digitalOrigin>re formatted digital</digitalOrigin> 

<extent>l print on board (poster) : silkscreen, color . </extent> 

</physicalDescription> 

<abstract>Poster promoting President Franklin Delano Roosevelt ' s 
four freedoms, showing a globe, two books, and the hand and torch 
from the Statue of Liberty . </abstract> 

<note>Exhibited in: American Responses to Nazi Book Burning, U.S. 
Holocaust Memorial Museum, Washington, D.C., 2003.</note> 
<subject authority= "lcsh "> 

<name type= "personal" authority="naf"> 

<namePart>Roosevelt, Franklin D. (Franklin Delano), 1882- 
1945</namePart> 
</name> 
</subject> 

<subject authority="lctgm"> 

<t opi c>Liberty</t opi c> 

<temporal>l 930-1 950</temporal> 
</subject> 

<subject authority="lctgm"> 

<topic>Freedom of speech</topic> 

<geographi oUnited States</geographi c> 

<temporal>l 930-1 950</temporal> 
</subject> 

<subject authority="lctgm"> 

<topic>Freedom of religion</topic> 

<geographi oUnited States</geographi c> 

<temporal>l 930-1 950</temporal> 
</subject> 

<identifier type=" local ">POS - WPA -PA .01 .F1439, no. 
1 </i den tifi er> 

<relatedltem type="host" displayLabel="Part of"> 
<titleInfo> 

<title>Work Projects Administration Poster Collection (Library 
of Congress) </title> 
</titleInfo> 
</relatedItem> 

<identifier type=" local ">cph 3f 05436 

http: //hdl . loc.gov/loc.pnp/cph. 3f05436</identifier> 

<location> 

<url usage= "primary display" access=" object in 
context ">http: //hdl . loc . gov/loc . pnp/cph . 3f05436</url> 

</location> 

<location> 

<physicalLocation>Library of Congress Prints and Photographs 
Division Washington, D.C. 20540 USA </physicalLocation> 
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</location> 

<accessCondition type="useAndReproduction"> There are no known 
restrictions on posters made by the Work Projects 
Administration . </accessCondition> 
<recordInfo> 

<recordCon tentSource 

author ity= "marcorg ">MdBJ</recordContentSource> 
<recordCreationDate encoding="w3cdtf">2005-10- 
28</recordCreati onDate> 

<recordChangeDate encoding="w3cdtf ">20 06-10-17 </recordChangeDate> 
<recordOrigin>Base MODS record derived from Library of Congress 
American Memory Project record, then edited to conform to the DLF 
Implementation Guidelines for Shareable MODS 
Records . </recordOrigin> 
<languageOfCataloging> 

<languageTerm authority= "iso639-2b ">eng</languageTerm> 
</languageOfCataloging> 
</ recordInfo> 
</mods> 

Example 6: Record for sheet music (Indiana University Bloomington) 

<mods xmlns= "http : //www. loc . gov/mods/v3 " 

xmlns :xsi= "http: //www. w3 . org/2001 /XMLSchema-instance " 

xsi : schemaLocation= "http : //www. loc . gov/mods/v3 

http: //www. loc . gov/ standards /mods /v3/mods-3-2 . xsd"> 
<titleInfo> 

<title>Spring and fall</title> 
<subTitle>a tone poem</subTitle> 
</titleInfo> 

<titleInfo type=" alternative" displayLabel= "First line"> 

<title>Spring was here</title> 

<nonSort>The </n onSort> 
</titleInfo> 

<name type= "personal" author ity="naf"> 
<n amePart >Berlin, Irvi n g</n amePa rt> 
<namePart type="date ">1888-</namePart> 
<role> 

<roleTerm author ity= "marcrelator " 
type= "text ">Composer</roleTerm> 

<roleTerm author ity= "marcrelator" type="code">cmp</roleTerm> 
</role> 
</name> 

<name type= "personal" authority="naf"> 
<namePart>Buck, Gene</namePart> 
<role> 

<roleTerm author ity= "marcrelator" 
type= "text ">Illustrator</roleTerm> 

<roleTerm authority= "marcrelator" type="code">ill</roleTerm> 
</role> 
</name> 

<typeOfResource>notated music</typeOfResource> 
<genre authority="lcsh">Love songs</genre> 
<genre authority="lcsh">Songs with piano</genre> 
<originInfo> 
<place> 
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<placeTerm type="code " authority= "marccountry " >nyu</placeTerm> 
<placeTerm type="text">New York</placeTerm> 
</place> 

<publisher>Ted Snyder Co . </publisher> 

< copy right Date encoding= "w3cdtf" 

keyDate= "yes ">1912</copyrightDate> 
</originInfo> 
<language> 

<languageTerm type="text ">English</languageTerm> 

<languageTerm type="code" authority="iso639- 

2b ">eng</ 1 anguage Term> 
</language> 
<physicalDescription> 

<form author i ty= "marcform ">print</form> 

<internetMediaType>image/ jpeg</ ±nternetMed±aType> 

<extent>l score (5 p.) : ill. ; 35 cm. </ extent > 

<digitalOrigin>re formatted digital</digitalOrigin> 
</physicalDescription> 
<note>For voice and piano. </note> 

<note>Publisher ' s advertising includes musical incipits . </note> 
<subject authority= "lcsh "> 

<t opi c>Seasons</t opi c> 
</subject> 

<subject authority= "lcsh "> 

<t opi c>Spring</ 1 opi c> 
</subject> 

<subject authority= "lcsh "> 

<t opi c>Aut umn </ topio 
</subject> 
<identifier 

type= "uri ">http: //purl . dlib . Indiana . edu/iudl/lilly/starr/LL-SSM- 

ALD3729 </ identifier 

<location> 

<physicalLocation>Lilly Library, Indiana University 
Bloomington</physicalLocation> 

<url usage= "primary display" access=" object in 

context ">http : //purl . dlib . Indiana . edu/ iudl/lilly/ Starr /LL-SSM- 
ALD3729 </url> 
</location> 

<accessCondition type="useAndReproduction">Use of this public-domain 

resource is unrestricted. </accessCondition> 

<recordInfo> 

<recordCon tentSource 

author ity="marcorg ">IUL</recordContentSource> 
<recordCreationDate encoding="w3cdtf ">1 999-03- 
2 9</re cordCrea t i onDa te> 

<recordChangeDate encoding="w3cdtf">2006-10-14</recordChangeDate> 
<recordIdentifier source=" InU-Li ">LL-SSM- 
ALD3729</recordIdentifier> 

<recordOrigin>Base MODS record derived from MARC21 record, then 
edited to conform to the DLF/Aquifer Implementation Guidelines 
for Shareable MODS Records . </recordOrigin> 
<languageOfCataloging> 

<languageTerm authority= "iso639-2b ">eng</languageTerm> 
</languageOfCataloging> 
</ recordInfo> 
</mods> 
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Example 7: Record for a physical artifact (University of Illinois at Urbana- 
Champaign) 

<mods xmlns= "http : //www. loc . gov/mods/v3 " 
xmlns :xsi= "http: //www. w3 . org/2001 /XMLSchema-instance " 
xsi : schemaLocation= "http : //www. loc . gov/mods/v3 
http: //www. loc.gov/standards/mods/v3/mods-3-2 .xsd"> 
<titleInfo> 

<title> Life Mask of Stephen A. Douglas</title> 
</titleInfo> 

<name type= "personal" authority="naf"> 

<namePart>Volk, Leonard Wells</namePart> 
<namePart type="date ">1828-1895</namePart> 
<role> 

<roleTerm author ity= "marcrelator " 
type= "text ">Sculptor</roleTerm> 

<roleTerm authority= "marcrelator" type="code">scl</roleTerm> 
</role> 
</name> 

<typeOfResource>three dimensional object </typeOfResource> 

<genre authority="aat">life masks</genre> 

<genre authority="aat">casts (sculpture) </genre> 

<originInfo> 

<dateCreated encoding="w3cdtf" keyDate="yes" 
qualifier=" approximate ">1857</dateCreated> 

</ originInfo> 

<physicalDescription> 

<form authority="gmd">art original</form> 
<internetMediaType>image/jpeg</internetMediaType> 
<digitalOrigin>re formatted digital</digitalOrigin> 

</physicalDescription> 

<abstract>This is a life mask of Stephen A. Douglas created by 
Leonard Volk in 1857. Douglas, who was related to Volk by marriage, 
sent him to Rome in 1856 to perfect his craft. Upon Volk's return in 
1857, he made a life mask of Douglas . </abstract> 
<subject authority= "lcsh "> 

<name type= "personal" author ity="naf"> 

<namePart>Douglas , Stephen Arnold</namePart> 

<namePart type="date ">1813-1861</namePart> 

</name> 
</subject> 
<location> 

<physicalLocation>University of Illinois at Urbana-Champaign . 
Library. Rare Book Room</physicalLocation> 
<url usage= "primary display" access=" object in 
context ">http : //images . library. uiuc . edu : 8081/u ?/tdc, 252</url> 
</location> 

<accessCondition type="useAndReproduction">Use of this public-domain 

resource is unrestricted . </accessCondition> 

<recordInfo> 

<recordContent Source authority="marcorg">IU</recordContentSource> 
<recordOrigin>Mapped from a Qualified Dublin core record to 
MODS. </recordOrigin> 
<languageOfCataloging> 

<languageTerm author ity=" iso639-2b">eng</languageTerm> 
</languageOfCataloging> 
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</ recordInfo> 
</mods> 

Example 8: Record for a born digital item (Emory University) 

<mods xmlns= "http : //www. loc . gov/mods/v3 " 
xmlns :xsi= "http: //www. w3 . org/2001 /XMLSchema-instance " 
xsi : schemaLocation= "http : //www. loc . gov / 'mods /v3 
http: //www. loc.gov/standards/mods/-v3/mods-3-2.xsd"> 

<titleInfo> 

<titl e>Roadsi de archi tecture </t itle> 

</tltleInfo> 

<name type= "personal" author ity="naf"> 
<namePart>Wharton, David</namePart> 
<namePart type= "date ">1 94 7-</namePart> 
<role> 

<roleTerm type="text" 

authority= "marcrelator ">Creator</roleTerm> 
</role> 
<role> 

<roleTerm type="text" 

authority= "marcrelator ">Author</roleTerm> 
</role> 
<role> 

<roleTerm type="text" 

authority= "marcrelator ">Photographer</roleTerm> 
</role> 
</name> 

<typeOfResource>still image</typeOfResource> 
<typeOfResource>text</typeOfResource> 
<genre author ity= "mar cgt ">picture</genre> 
<origlnInfo> 
<place> 

<placeTerm type="text">Atlanta, Ga . </placeTerm> 
<placeTerm type="code " authorlty="marccountry">gau</placeTerm> 
</place> 

<publisher>Metascholar Initiative at Emory University</publisher> 
<datelssued encoding="w3cdtf" keyDate="yes">2005-02- 
01</datelssued> 

</originInfo> 

<language> 

<languageTerm type="text ">English</languageTerm> 

<languageTerm type="code" authority="iso639- 

2b " >eng</ languageTerm> 
</language> 
<physicalDescription> 

<internetMediaType>image/jpeg</internetMediaType> 

<internetMediaType>text/html</internetMediaType> 

<extent>l electronic text, 19 photographs, 1 map</extent> 

<digital Ori gin>born digital </di gital Ori gin> 
</physicalDescription> 

<abstract displayLabel=" summary ">Since coming to Mississippi in 
1999, David Wharton has been photographing the social and cultural 
landscape of the mid-South with an emphasis on rural and small-town 
life. This photo essay on buildings in rural and small-town settings 
in Mississippi and other parts of the Deep South features eighteen 
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of Wharton's photographs taken between 1999 and 2004. Included with 
the exhibit is Wharton ' s introductory narrative and a map displaying 
the locations of his photographs . </abstract> 

<tableOfContents>Abstract — Photo essay sections: Introduction — 
Photo Essay — Map and recommended resources</tableOfContents> 
<subject authority= "lcsh "> 

<t opi oRoadside archi tect ure</t opi c> 

<geographic>Southern States</geographic> 

<genre>Pictorial works</genre> 
</subject> 

<subject authority= "lcsh "> 

<topi oRoadside architect ure</t opi c> 

<geographic>Mississippi</geographic> 

<genre>Pictorial works</genre> 
</subject> 

<subject author ity=" lcsh" > 

<topi ORoadside architect ure</t opi c> 

<topic>Social aspects</topic> 
</subject> 

<subject authority= "tgn "> 

<geographic>Southern United States (general region) </geographic> 
</subject> 

<subject author ity=" local" > 

<topic>Art and architecture</topic> 
</subject> 

<subject author ity=" tgn" > 

<geographic>Mississippi (State) </geographic> 
</subject> 
<subject> 

<geographicCode authority= "marcgac ">n-usu</geographicCode> 
</subject> 
<subject> 

<cart ographics> 

<coordinates>W035.459 W029.850 N035.459 N029 . 850</coordinates> 
</cart ographics> 
</subject> 
<subject> 

<temporal encoding="w3cdtf" point=" start ">1999</temporal> 
<temporal encoding="w3cdtf" point="end">2004</temporal> 
</subject> 

classification author ity=" Ice" >F 216 . 2</classification> 
<relatedltem type="host" displayLabel=" Appears in"> 

<titleInfo> 

<title>Southern Spaces</title> 

</titleInfo> 

<genre author ity=" lcsh" >Electronic journals</genre> 
<identifier type=" issn ">1551-2754</identifier> 
<location> 

<url>http : //www. southernspaces . org</url> 
</location> 
</related!tem> 
<identifier 

type= "uri ">http: //www. southernspaces . org /contents/ 2005 /wharton/ la. ht 

m</ i den tifi er> 

<location> 

<url usage= "primary display" access=" object in context "> 

http: //www. southernspaces . org/ contents/ 2005 /wharton/ la . htm</url> 
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</location> 

<accessCondition type="useAndReproduction">Copyrlght for 
contributions published in the Southern Spaces forum is retained by 
the authors, with publication rights granted to the forum. Content 
is free to users. Any reproduction of original content from Southern 
Spaces must a) seek copyright from authors and b) acknowledge 
Southern Spaces as the site of original 
publication. </accessCondition> 
<recordInfo> 

<languageOfCataloging> 

<languageTerm authority= "iso639-2b ">eng</languageTerm> 

</langua geOfCa taloging> 

<recordCon tentSource 

author ity="marcorg ">GEU</recordContentSource> 

<recordOrigin>MODS record created by Emory University Libraries 
sta ff</re cordOri gin> 
</ recordInfo> 
</mods> 
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